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

On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio <israelh@microsoft.com> wrote:
> What is the expected behavior when calling update() in a cursor index that requires unique values.  Firefox allows the update, even when it results in a duplicate value.  Chrome throws an error event with the code set to UNKNOWN_ERR.

Huh? That seems very bad if we allow duplicate data to be created and
violate a unique constraint, no matter what API it happens through.
Can you provide a testcase and I'll file a bug on Firefox.

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

We can't really throw an error since we don't synchronously know that
there is a collision. However we should fire an error event with .code
set to CONSTRAINT_ERR if there is a collision. Indeed it seems like
the spec already demands this. IDBCursor.update says to run the "steps
for storing a record into an object store". Those steps define that if
a unique constraint is violated a CONSTRAINT_ERR is reported. This
happens in step 7.5 and 7.6.

/ Jonas