W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [indexeddb] Calling update on a cursor index with a unique value constraint

From: Jeremy Orlow <jorlow@chromium.org>
Date: Fri, 8 Jul 2011 01:13:17 -0700
Message-ID: <CADBqD60VTe5v1-RhoqKajt1mfkyVTUun2LWyFTgaqO1LcMjhcQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Israel Hilerio <israelh@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Adam Herchenroether <aherchen@microsoft.com>
On Thu, Jul 7, 2011 at 1:46 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Jul 6, 2011 at 9:41 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> > On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio <israelh@microsoft.com>
> >> We believe an error should be thrown because of the violation of the
> >> unique value index constraint and the error code should be set to
> >> CONSTRAINT_ERR.  What do you think?
> >
> > IIRC, we decided update should essentially be an alias to delete and then
> an
> > add on the parent object store--probably an atomic one.  So by that logic
> it
> > does seem to me CONSTRAINT_ERR would be the right error.
>
> Hmm.. it's not exactly a delete and a add since if the add produces an
> error but the error handler calls .preventDefault, you don't want only
> the delete to be executed.
>
> I'd rather say that a .update is the same as a .put.
>
> > Btw, ObjectStore.add()'s exception section doesn't mention CONSTRAINT_ERR
> > though it probably should.
>
> IDBObjectStore.add never throws CONSTRAINT_ERR since that's detected
> asynchronously, so the spec seems fine here. However
> IDBObjectStoreSync.add and IDBObjectStoreSync.put should and does list
> it as an exception.
>

Oops....yeah...just got mixed up.
Received on Friday, 8 July 2011 08:13:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT