RE: [IndexedDB] deleteObjectStore method and updates to IDBDatabase.objectStoreNames on the client

May these updates:

Updated the IDBDatabase.deleteObjectStore method to return void.

For IDBDatabase.deleteObjectStore and IDBDatabase.createObjectStore added a sentence to the description to say:
This method will synchronously modify the IDBDatabase.objectStoreNames property.              

For IDBObjectStore.deleteIndex and IDBObjectStore createIndex added a sentence to the description to say:
This method will synchronously modify the IDBObjectStore.indexNames property.

Thanks,

Eliot

> -----Original Message-----
> From: public-webapps-request@w3.org [mailto:public-webapps-
> request@w3.org] On Behalf Of Jonas Sicking
> Sent: Wednesday, May 04, 2011 1:21 PM
> To: Jeremy Orlow
> Cc: Israel Hilerio; public-webapps@w3.org
> Subject: Re: [IndexedDB] deleteObjectStore method and updates to
> IDBDatabase.objectStoreNames on the client
> 
> On Wed, May 4, 2011 at 9:49 AM, Jeremy Orlow <jorlow@chromium.org>
> wrote:
> > On Wed, May 4, 2011 at 9:40 PM, Israel Hilerio <israelh@microsoft.com>
> > wrote:
> >>
> >> The reason I was thinking that deleteObjectStore was async was
> >> because it returns an IDBRequest interface and the pattern implies
> >> that the onsuccess handler needs to be called for me to be sure that
> >> the operation happened successfully.
> >
> > I'm pretty sure this is just an oversight.  There's no mention of
> > things being async in the description, it returns exceptions, and
> > deleteIndex returns void.  I don't see any reason why
> > deleteObjectStore would be different.
> >
> >>
> >> Regarding the createObjectStore, it returns immediately but the the
> >> actual object store creation could happen asynchronously in the
> >> background. At least there is language in the spec that alludes to that fact:
> >>
> >> "In some implementations it's possible for the implementation to
> >> asynchronously run into problems creating the object store after the
> >> createObjectStore function has returned. . Such implementations must
> >> still create and return a IDBObjectStore object. Instead, once the
> >> implementation realizes that creating the objectStore has failed, it
> >> must abort the transaction using the steps for aborting a transaction."
> >
> > Sure, but besides the fact that the transaction may spuriously abort
> > (which is unfortunate), all other side effects should be hidden from
> > the user.  We should just spec that the name should immediately show up
> in the list.
> >
> >>
> >> If we believe that the actual object store creation needs to happen
> >> synchronously to establish a common behavior between platforms, we
> >> should stipulate that in the spec.
> >
> >
> > The entire design revolves around ensuring you'll never block on disk io.
> >  So we definitely should not do this.
> >>
> >> Back to the original issue, I like your statement of ensuring that
> >> the deleteObjectStore removes the objectStore name from the
> >> IDBDatabase.objectStoreNames immediately after it executes.
> >> If everyone else agrees, we should add some text or a note to the
> >> spec to capture this.
> >
> > Making it return void should be enough.
> >
> >>
> >> Israel
> >>
> >> On Wed, May 4, 2011 at 9:17 PM, Jeremy Orlow wrote:
> >> > Well, createObjectStore is synchronous, so that one's easy.
> >> > Everything happens at once in terms of side effects.
> >> >
> >> > As for delete: why is this asynchronous again?  It seems easiest
> >> > just to make it sync unless there's some major problem with doing so.
> >> >
> >> > Either way, it seems that the change to objectStoreNames should
> >> > either happen immediately or when firing the onsuccess event (i.e.
> >> > not just at some random time in between).
> >> >
> >> > J
> >> > > On Wed, May 4, 2011 at 7:13 AM, Israel Hilerio
> >> > > <israelh@microsoft.com>
> >> > > wrote:
> >> > > In looking at createObjectStore on IDBDatabase, it seems that we
> >> > > would have to update the IDBDatabase.objectStoreNames attribute
> >> > > on the client side after returning the IDBObjectStore.
> >> > > Otherwise, it would be difficult > > to detect that an
> >> > > objectStore with the same name already exists and throw a
> CONSTRAINT_ERR exception.
> >> > >
> >> > > Following this pattern, would it make sense to update the
> >> > > IDBDatabase.objectStoreNames attribute on the client side after
> >> > > executing deleteObjectStore before the async operation is
> >> > > executed.  This would allow us to support scenarios like:
> >> > >
> >> > > var b = db.createObjectStore(B);
> >> > > var req = db.deleteObjectStore(B); b = db.createObjectStore(B);
> >> > >
> >> > > What do you think?
> >> > >
> >> > > Israel
> 
> I agree with Jeremy.
> 
> We should just make deleteObjectStore return void and then define that
> deleteObjectStore/createObjectStore/deleteIndex/createIndex all act
> synchronously and modify .objectStoreNames/.indexNames synchronously.
> 
> Israel: I'm not sure what you mean by that you think "object store creation
> needs to happen synchronously". I definitely agree that creating the
> IDBObjectStore object should happen synchronously, and that it should be
> added to the .objectStoreNames array synchronously.
> 
> Anything beyond that is opaque to the website and so I don't think it makes
> sense to say anything normative about it.
> 
> / Jonas
>

Received on Saturday, 11 June 2011 00:11:33 UTC