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

On Wed, Oct 26, 2011 at 9:34 AM, Joshua Bell <jsbell@chromium.org> wrote:
> 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

Even if there are indexes (which I don't think will always be the
case), the implementation can keep track of which key ranges have been
deleted. If a query is made against an index, the implementation can
check if the values of the index are within that key range and skip
them.

So I would not be surprised if once implementations start optimizing
heavily, they'll run into instances where returning true/false will be
slower.

/ Jonas

Received on Wednesday, 26 October 2011 23:30:34 UTC