Sorting the events by the start date leads to more predictable results for the search API consumers.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
Event recurrences are evaluated at runtime because the database only knows the first and last occurrence.
Given, a user created 8 events with a yearly reoccurrence and two for events tomorrow.
The upcoming event widget asks the CalDAV backend for 7 events within the next 14 days.
If limit 7 is applied to the SQL query, we find the 7 events with a yearly reoccurrence and discard the events after evaluating the reoccurrence rules because they are not due within the next 14 days and end up with an empty result even if there are two events to show.
The workaround for search requests with a limit and time range is asking for more row than requested and retrying if we have not reached the limit.
Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
pruneOutdatedSyncTokens accidentally deletes all entries of the calendarchanges table
instead of leaving $limit elements in the table
Signed-off-by: Christof Arnosti <charno@charno.ch>
Now that we're in a transaction, we can reuse the sync token's previous value without trouble, and rewrite the increment UPDATE query without dirty direct SQL.
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
In a lot of methods we're doing read-after-writes (for instance calling
updateProperties after touching calendar objects).
There's also a lot of deleting methods that do stuff sequentially which
could cause trouble.
This should avoid this kind of issues.
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
We do not support events after 2038 on 32bits but still behave better
when date range start/end is after 2038.
Signed-off-by: Côme Chilliet <come.chilliet@nextcloud.com>
We remove all outdated sync tokens, based on their auto-incremented ID.
By default we only keep the last 10 000, but this can be configurable.
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
- Introduce a new CalendarObjectMovedEvent typed event dedicated for
this operation
- Handle the event in the activity backend and add new appropriate activity subjects
Signed-off-by: Thomas Citharel <tcit@tcit.fr>
The timestamp is an int, but we treated it as string. With this patch
the property map is enriched with types and settype casts the value if
necessary.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
When we search for CalDAV objects in the DB we take the first and last
occurence into account. For recurring events that is when they take
place the very first time and the very last time. Searching in a more
specific time range will still match this condition, because the
recurring event starts before the end of the requested range but ends
after the start of the requested range.
Sabre has filters for this. If we apply them on all seach objects of a
search with a time range, then only the recurring events actually taking
place at the time of the requested time range will be returned.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
For API users it looked like any properties could be searched. But it
turned out to be a hand picked list of properties that we index and then
use for the search. To prevent application errors where special props
are not found, I suggest we document and type the allowed values.
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
