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.