- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 7 Jul 2011 13:41:13 -0700
- 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