Split the DB requests in chunk of 1000 and use INNER JOIN instead of IN
as this is better supported on all DB.
Signed-off-by: Carl Schwan <carl.schwan@nextcloud.com>
This adds support for all Doctrine supported types, for the column types only the immutable variants needed to be added.
But especially those types are the important ones, as our **Entity** class works by detecting changes through setters.
Meaning if it is mutable, changes like `$entity->date->modfiy()` can not be detected, so the immutable types make more sense here.
Similar the parameter types needed to be added.
`Enity` and `QBMapper` needed to be adjusted so they support (auto map) those types, required when insert or update an entity.
Also added more tests, especially to make sure the mapper really serializes the values correctly.
Co-authored-by: Ferdinand Thiessen <opensource@fthiessen.de>
Co-authored-by: Côme Chilliet <91878298+come-nc@users.noreply.github.com>
Signed-off-by: Ferdinand Thiessen <opensource@fthiessen.de>
- Reflect the actual return value returned by the implementation in the
the interface. E.g. IUser|bool -> IUser|false
- Remove $hasLoggedIn parameter from private countUser implementation.
Replace the two call with the equivalent countSeenUser
- getBackend is nuallable, add this to the interface
- Use backend interface to make psalm happy about call to undefined
methods. Also helps with getting rid at some point of the old
implementActions
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
This is helpful in cases where we are deleting tons jobs at the same
time in a gallera cluster. This doesn't happen often but this can create
issues.
Test plan:
1. Use https://github.com/nextcloud/quota_warning/pull/88
2. Change max to 1
3. Enabled/Disable quota_warning app and see jobs getting sucessfully
added and removed
Signed-off-by: Carl Schwan <carl@carlschwan.eu>
Because executeUpdate wasn't a great name. And in DBAL they also use
executeStatement more consistently now.
Ref https://github.com/doctrine/dbal/issues/4607
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Names shamelessly copied from Doctrine itself.
Internally it is still using the same flow. But I added some checks
around it.
This should make static analysis a bit more happy. Which in turn makes
me more happy.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>