Re: [indexeddb] Calling update on a cursor index with a unique value constraint
On Thu, Jul 7, 2011 at 1:46 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Jul 6, 2011 at 9:41 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio isra...@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. Oopsyeah...just got mixed up.
Re: [indexeddb] Calling update on a cursor index with a unique value constraint
On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio isra...@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
Re: [indexeddb] Calling update on a cursor index with a unique value constraint
On Wed, Jul 6, 2011 at 9:41 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio isra...@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
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 jor...@chromium.org wrote: On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio isra...@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 text/html; name="cursor_update_unique.htm": Unrecognized
Re: [indexeddb] Calling update on a cursor index with a unique value constraint
On Thu, Jul 7, 2011 at 6:35 PM, Israel Hilerio isra...@microsoft.com wrote: On Thursday, July 07, 2011 1:46 PM, Jonas Sicking wrote: On Wed, Jul 6, 2011 at 9:41 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio isra...@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. Thanks! 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
[indexeddb] Calling update on a cursor index with a unique value constraint
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. 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? Israel
Re: [indexeddb] Calling update on a cursor index with a unique value constraint
On Wed, Jul 6, 2011 at 10:06 AM, Israel Hilerio isra...@microsoft.comwrote: 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. Most (if not all?) of the times Chrome throws an UNKNOWN_ERR, it's because the functionality simply hasn't been implemented yet. 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. Btw, ObjectStore.add()'s exception section doesn't mention CONSTRAINT_ERR though it probably should. J
