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:41:13 -0700
Message-ID: <CA+c2ei8c--4HPativXX1jFcz5PDVw1SSbu+jWeOkNBX21qdjUg@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>, Adam Herchenroether <aherchen@microsoft.com>
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
Received on Thursday, 7 July 2011 20:42:10 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:33 UTC