We can assume that after a few seconds a read will be clean again.
This is helpful for false warnings in long running processes.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Postgres 10 is the minimum in the meantime
and doctrine/dbal fixed this in 2.6.0 already
ref https://github.com/doctrine/dbal/pull/2614
Signed-off-by: Joas Schilling <coding@schilljs.com>
fix(sqlite): Remove no longer required autoincrement fix
- I installed current master and exported the schema as SQL
- Then I went to this branch, removed the content of the run() method (so made it no-op)
- I installed again and exported the schema as SQL
- The files are exactly the same, so whatever we tried to fix was fixed since 2015 in doctrine dbal
Signed-off-by: Joas Schilling <coding@schilljs.com>
This seems to be a left over after abstracting DBAL. Nowadays,
IQueryBuilder::executeStatement() only throws a \OCP\DB\Exception, where
previously original DBAL exceptions where thrown. These are now wrapped,
the orignal classes are now mapped to a reason.
Signed-off-by: Arthur Schiwon <blizzz@arthur-schiwon.de>
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>
executeUpdate is deprecated in favor of executeStatement.
We overwrote the old one hence the prefix was no longer replaced.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
Format control structures, classes, methods and function
To continue this formatting madness, here's a tiny patch that adds
unified formatting for control structures like if and loops as well as
classes, their methods and anonymous functions. This basically forces
the constructs to start on the same line. This is not exactly what PSR2
wants, but I think we can have a few exceptions with "our" style. The
starting of braces on the same line is pracrically standard for our
code.
This also removes and empty lines from method/function bodies at the
beginning and end.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>