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: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 7 Jul 2011 13:46:10 -0700
Message-ID: <CA+c2ei8UKBrKzGuGYuRXZ+72HUoJmvWGpUMBWYz+TbTQ-Yspdg@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Israel Hilerio <israelh@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Adam Herchenroether <aherchen@microsoft.com>
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.

/ Jonas
Received on Thursday, 7 July 2011 20:47:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:22 UTC