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

On Thu, Jul 7, 2011 at 6:35 PM, Israel Hilerio <> wrote:
> On Thursday, July 07, 2011 1:46 PM, Jonas Sicking wrote:
>> On Wed, Jul 6, 2011 at 9:41 PM, Jeremy Orlow <>
>> wrote:
>> > On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio
>> > <>
>> >> 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.

See the "and does" part above. It's already there :)

/ Jonas

Received on Friday, 8 July 2011 02:06:04 UTC