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

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
>
>