On Tue, 2011-10-25 at 09:24 +0200, Lukas Zeller wrote: > Hello Patrick, > > On Oct 24, 2011, at 16:55 , Patrick Ohly wrote: > > > Why is it necessary to read before trying to delete? If the item exists, > > then reading it is a fairly expensive test. > > Unfortunately, with some some backends, this is the only test that > reliably works. For example, some SQL databases (or their ODBC driver) > can't return a correct "number of affected rows" for DELETE > statements. So reading before deleting was the only way to detect if > any of the subdatastores really had that item and correctly return 404 > or 200. > > > So far, my backends were written with the expectation that they have to > > cope with delete requests for items which are already deleted. This > > follows from the inherent race condition between syncing and some other > > process which might delete items while a sync runs. > > > > Are all backends expected to return 404 when an item doesn't exist? > > Not all backends (see above, built-in ODBC can't), but yes, for plugin > backends, returning proper error codes is specified, also for delete.
Are these expectations documented somewhere? I'm still a bit fuzzy about which error codes are expected. For example, should a delete of a non-existent item succeed (200) or fail (404)? > Still, if a plugin would not conform to that in its implementation of > delete, that would probably have gone unnoticed so far. Right. SyncEvolution has hardly ever (never?) returned 404 and that has not been an issue until now ;-) > Of course, the test is a bit expensive - if that's a concern, one > could differentiate between plugin datastores and others (all the > builtin ones, including SQL/ODBC), and use the expensive read test > only for the latter. Like a virtual dsDeleteDetectsItemPresence() > which returns false by default, but can be overridden in plugin > datastores to return true. That sounds like the right compromise. I'm much more comfortable returning 404 in a delete and not reporting that to the user as an error, compared to not reporting a 404 in a ReadItem call (as I have to do now). -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
