Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>
Co-authored-by: Richard Steinmetz <richard@steinmetz.cloud>
Signed-off-by: Sebastian Krupinski <165827823+SebastianKrupinski@users.noreply.github.com>
Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>
Co-authored-by: Richard Steinmetz <richard@steinmetz.cloud>
Signed-off-by: Sebastian Krupinski <165827823+SebastianKrupinski@users.noreply.github.com>
Co-authored-by: Richard Steinmetz <richard@steinmetz.cloud>
Signed-off-by: Sebastian Krupinski <165827823+SebastianKrupinski@users.noreply.github.com>
Co-authored-by: Richard Steinmetz <richard@steinmetz.cloud>
Signed-off-by: Sebastian Krupinski <165827823+SebastianKrupinski@users.noreply.github.com>
Co-authored-by: Daniel <mail@danielkesselberg.de>
Signed-off-by: Sebastian Krupinski <165827823+SebastianKrupinski@users.noreply.github.com>
Signed-off-by: SebastianKrupinski <krupinskis05@gmail.com>
Address book and calendar sync tokens have a created_at column in 26+
and we need to assign a current timestamp to the existing data at
upgrade so the data isn't cleaned up immediately. Updating the full
table is expensive and fails on clustered setups that limit transaction
size. We don't need a timestamp for the oldest rows so we can skip
updating them.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
- Switch back to countUsers to have the actual value. countSeenUsers is bad if Nextcloud is connected to a larger directory, but only a part is using Nextcloud and therefore the seen count is much lower because the sync is done for all users.
- Lower the threshold to 100 for smaller installations.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
countUsers: the actual user count reported by the backend.
countSeenUsers: count every user who was logged in once.
1: We should avoid expensive operations (like asking every backend for it's user count) in migrations.
2: The current check is wrong because countUsers returns an array. var_dump([] > 1000) => true ;)
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
The current implementation only saves them as string. It seems they can
be more complex than that, and that objects were saved directly.
You may find such objects saved in some production databases by
executing:
```sql
SELECT * from oc_properties where propertyvalue = 'Object';
```
This commit adds a repair job to clean all of these "broken" properties
values, adds a new database column to save the type of the property, and
handles converting from and to correct values.
Implementation is very similar to SabreDAV's own PDO backend: 4921806dfb/sabre/dav/lib/DAV/PropertyStorage/Backend/PDO.php
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
Those indexes are already covered by others. So those can just be used.
THose extra indexes just take up space.
Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
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>
