Right now our API exports the Doctrine/dbal exception. As we've seen
with the dbal 3 upgrade, the leakage of 3rdparty types is problematic as
a dependency update means lots of work in apps, due to the direct
dependency of what Nextcloud ships. This breaks this dependency so that
apps only need to depend on our public API. That API can then be vendor
(db lib) agnostic and we can work around future deprecations/removals in
dbal more easily.
Right now the type of exception thrown is transported as "reason". For
the more popular types of errors we can extend the new exception class
and allow apps to catch specific errors only. Right now they have to
catch-check-rethrow. This is not ideal, but better than the dependnecy
on dbal.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
As per https://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html
CREATE TABLE statements automatically commit always. The only reason
this worked in the past was that PHPs PDO connection didn't check the
actual state on commit, but only checked their internal state.
But in PHP8 this was fixed:
https://github.com/php/php-src/blob/PHP-8.0/UPGRADING#L446-L450
So now commit() fails because the internal PDO connection implicitly
commited already.
Signed-off-by: Joas Schilling <coding@schilljs.com>
Otherwise those apps might not be loaded when the others app migrations
are running. The previous loading of authentication apps in the upgrade
step never worked as it just returns in maintenance mode
Signed-off-by: Julius Härtl <jus@bitgrid.net>
Right now any setup error will just result in the exception message
being printed. In some cases this doesn't give any insights into what
went wrong. This adds some dedicated logic to print the exception trace
and any previous exceptions to the CLI.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
The error that gets thrown can also be a type error etc. So we should
properly catch the Throwable.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
this allows authenticating with passwords that contain non ascii-characters in contexts that otherwise do not allow it (http basic)
Signed-off-by: Robin Appelman <robin@icewind.nl>
Found while debugging a customer setup. They had to flush their Redis.
Hence the info was no longer there. Since they also used S3 this meant
requesting the files over and over on template render. Which on S3 is
not cheap.
Now we just write it back if we can't get it from the cache in the first
place. So that the next run has it cached properly again.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
* Event object as first arg (otherwise there is a notice in the logs)
* `dispatch` MUST return the event object
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>