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

On Thursday, July 07, 2011 1:46 PM, Jonas Sicking 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.
> 
> / Jonas

Attached is the sample page you requested.  The sample creates a unique index on the property "foo" and updates a record with a duplicate value for "foo". In FF, I was able to update the entry with a duplicate value for "foo".  I agree with you that we should generate an error event with a .code set to CONSTRAIN_ERR if there is a collision when calling .update.  

Also agree that we should update the IDBObjectStoreSync.add and IDBObjectStoreSync.put to include CONSTRAINT_ERR as part of its exception list.

Israel