Re: [IndexedDB] IDBRequest.abort on writing requests

On Tue, Jul 13, 2010 at 1:17 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Tue, Jul 13, 2010 at 8:25 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> Hi All,
>>
>> Sorry if this is something that I've brought up before. I know I meant
>> to bring this up in the past, but I couldn't find any actual emails.
>>
>> One thing that we discussed while implementing IndexedDB was what to
>> do for IDBRequest.abort() or "writing" requests. For example on the
>> request object returned from IDBObjectStore.remove() or
>> IDBCursor.update().
>>
>> Ideal would of course be if it would cancel the write operation,
>> however this isn't always possible. If the call to .abort() comes
>> after the write operation has already executed in the database, but
>> before the 'success' event has had a chance to fire. What's worse is
>> that other write operations might already have been performed on top
>> of the aborted request. Consider for example the following code:
>>
>> req1 = myObjectStore.remove(12);
>> req2 = myObjectStore.add({ id: 12, name: "Benny Andersson" });
>> .... do other stuff ....
>> req1.abort();
>>
>> In this case, even if the database supported aborting a specific
>> operation, it's very hard to say what the correct thing to do with
>> operations performed after it. As far as I know, databases generally
>> don't support rolling back a given operation, only rolling back to a
>> specific point, i.e. rolling back a given operation and all operations
>> performed after it.
>>
>> We could say that abort() signals some sort of error if the operation
>> has already been performed in the database, however that makes abort()
>> very racy.
>>
>> Instead we concluded that the best thing to do was to specify that
>> IDBRequest.abort() should throw if called on a modifying request. If
>> this sounds good I'll make this change to the spec.
>
> I'd be fine with that.
> Or we could remove abort all together.  I can't really think of what types
> of operations you'd really want to abort until (at least) we have some sort
> of join language or other mechanism to do really expensive read-only calls.

I think there are expensive-ish read-only calls. Indexes are
effectively a join mechanism since you'll hit one b-tree to do the
index lookup, and then a second b-tree to look up the full object in
the objectStore.

I don't really feel strongly either way. I think abort() isn't too
hard to implement, but also doesn't provide a ton of value. At least
not, like you say, until we add expensive calls like getAll or
multi-step joins.

> Or we could take abort off IDBRequest and instead put a rollback on
> transactions (and not do the modify limitation).

I definitely think we should have IDBTransaction.abort() no matter
what. And that should allow rolling back write operations.

/ Jonas

Received on Tuesday, 13 July 2010 20:42:22 UTC