Change the way event updates are handled
The previous implementation went to great lengths to avoid hitting
the database any more than necessary. Because event updates may
only be touching a handful of fields, this required handling a
variety of situations in which only partial data was available.
In some cases a few fields were queried from the database.
We want to validate requests more robustly as part of opening the
calendar provider, so we now pull the events out of the database,
merge them with the new values, and validate the result before
issuing the update.
"Bulk" updates are no longer issued as a single database command
(though they do all happen within a single transaction). Each event
update is validated individually. As a result, the partial-update
mechanism may be applied to events edited in bulk.
This doesn't introduce any new validation tests, but some of the
existing tests are now applied more broadly, so there is some risk of
previously-accepted requests being rejected.
The validateEventData() function was split into two parts. The code
that dealt with bad requests by stripping out undesirable fields
is now in scrubEventData(). Long-term we want to eliminate the
"scrub" pass.
Also, fixed the code that updates LAST_DATE in an update transaction
so that changing from a regular event or limited recurrence to an
infinitely-repeating recurrence causes LAST_DATE to be nulled out.
Bug 2519655,5057401
Change-Id: Ic5c510951334a11adb8bdc58c01d863bcf8bc01a
3 files changed