After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 754480 - Provide write conflict resolution API
Provide write conflict resolution API
Status: RESOLVED OBSOLETE
Product: evolution-data-server
Classification: Platform
Component: Calendar
3.16.x (obsolete)
Other Linux
: Normal enhancement
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2015-09-02 16:40 UTC by Milan Crha
Modified: 2021-05-19 11:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Milan Crha 2015-09-02 16:40:14 UTC
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1255140

There is currently (git master few weeks before 3.18.0) no write conflict resolution for calendar or book, thus, for example in the CalDAV calendar, if the backend tries to write changes of an event which changed on the server with an old ETag an HTTP 412 error (Precondition failed) can be returned on the PUT request.

The conflict resolutions for an object update can be:
 - fail - do not do anything, just fail (like it works now)
 - discard my changes
 - force my changes
 - add as a new object - that's not always applicable

Maybe a similar conflict resolution could be done when deleting objects, not only when updating them, but I'm not sure whether it makes any sense.

The conflict resolution shouldn't be automatic, because the code cannot always decide what to do. That means that the API should offer a user interaction.

Any opinion on the subject highly welcome.
Comment 1 Milan Crha 2015-09-03 06:03:49 UTC
One option would be to add a new argument to modify_object(s) function, what to do in case of conflicts, where the 'Fail' case would return a new E_CLIENT_ERROR, thus the client requesting the object modification could do what is necessary, including asking the user and so on.

The new argument might be even a boolean only, whether to fail on conflict or force the changes. Maybe it would be better than passing an enum and expecting each backend implementing all the relevant options - better to leave this to the clients. Maybe. (Once there'll be a meta-backend it'll be the opposite.)
Comment 2 André Klapper 2021-05-19 11:03:24 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. 
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow
  https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/

Thank you for your understanding and your help.