Re: [IndexedDB] IDBObjectStore.delete should accept a KeyRange

On Tue, Oct 25, 2011 at 4:50 PM, Israel Hilerio <israelh@microsoft.com>wrote:

> On Monday, October 24, 2011 7:40 PM, Jonas Sicking wrote:
> >
> > While I was there it did occur to me that the fact that the .delete
> function
> > "returns" (through request.result in the async API) true/false depending
> on if
> > any records were removed or not might be bad for performance.
> >
> > I suspect that this highly depends on the implementation and that in some
> > implementations knowing if records were deleted will be free and in
> others it
> > will be as costly as a .count() and then a .delete(). In yet others it
> could
> > depend on if a range, rather than a key, was used, or if the objectStore
> has
> > indexes which might need updating.
> >
> > Ultimately I don't have a strong preference either way, though it seems
> > unfortunate to slow down implementations for what likely is a rare use
> case.
> >
> > Let me know what you think.
> >
> > / Jonas
> >
>
> To clarify, removing the return value from the sync call would change its
> return signature to void.  In this case, successfully returning from the
> IDBObjectStore.delete call would mean that the information was successfully
> deleted, correct?  If the information was not successfully deleted, would we
> throw an exception?
>
> In the async case, we would keep the same return value of IDBRequest for
> IDBObjectStore.delete.  The only change is that the request.result would be
> null, correct?  If no information is deleted or if part of the keyRange data
> is deleted, should we throw an error event?  It seems reasonable to me.
>
>
When you write "If no information is deleted ... should we throw an error
event?" do you mean (1) there was no matching key so the delete was a no-op,
or (2) there was a matching key but an internal error occurred preventing
the delete? I ask because the second clause, "if part of the keyRange data
is deleted, should we throw an error event?" doesn't make sense to me in
interpretation (1) since I'd expect sparse ranges in many cases.

In the async case, interpretation (1) matches Chrome's current behavior:
success w/ null result if something was deleted, error if there was nothing
to delete. But I was about to land a patch to match the spec: success w/
true/false, so this thread is timely.

I agree with Jonas that returning any indication of whether data was deleted
could be costly depending on implementation. But returning success+null vs.
error is just as costly as success+true vs. success+false, so I'd prefer
that if we do return an indication, we do so using the boolean approach.

To Jonas' question: although I suspect that in most cases there will be
indexes and the delete operation will internally produce the answer
anyway, since script can execute a count() then delete() we probably
shouldn't penalize delete() and thus have it always return success+null. As
I mentioned, Chrome doesn't currently match the spec in this regard  so we
don't have users dependent on the spec'd behavior.

-- Josh

(apologies to anyone who received this twice; I sent it out from the wrong
email address first and it was caught by the w3.org filter)