On Monday, October 24, 2011 7:40 PM, Jonas Sicking wrote: > On Mon, Oct 24, 2011 at 11:28 AM, Jonas Sicking <[email protected]> wrote: > > On Mon, Oct 24, 2011 at 10:17 AM, Israel Hilerio <[email protected]> > wrote: > >> On Wednesday, October 12, 2011 2:28 PM, Jonas Sicking wrote: > >>> Currently IDBObjectStore.count/get/openCursor and > >>> IDBIndex.count/get/openCursor/openKeyCursor all take a key or a > KeyRange. > >>> However IDBObjectStore.delete only accepts keys. We should fix this > >>> to allow .delete to accept a KeyRange as well. > >>> > >>> / Jonas > >>> > >> > >> This makes sense to me. Is this something we still want to do? > > > > Yup, I think so. I was just waiting to hear back from others. I'll go > > ahead and make that change to the spec right away. > > I made this change. I still kept the difference that .delete(null) does not > work. > I.e. it doesn't match, and delete, all records in the store. It simply seems > like it > would make it too easy to accidentally nuke all the data from an object store. > We also already have the > .clear() function to do that. > > While I was there it did occur to me that the fact that the .delete function > "returns" (through request.result in the async API) true/false depending on if > any records were removed or not might be bad for performance. > > I suspect that this highly depends on the implementation and that in some > implementations knowing if records were deleted will be free and in others it > will be as costly as a .count() and then a .delete(). In yet others it could > depend on if a range, rather than a key, was used, or if the objectStore has > indexes which might need updating. > > Ultimately I don't have a strong preference either way, though it seems > unfortunate to slow down implementations for what likely is a rare use case. > > Let me know what you think. > > / Jonas >
To clarify, removing the return value from the sync call would change its return signature to void. In this case, successfully returning from the IDBObjectStore.delete call would mean that the information was successfully deleted, correct? If the information was not successfully deleted, would we throw an exception? In the async case, we would keep the same return value of IDBRequest for IDBObjectStore.delete. The only change is that the request.result would be null, correct? If no information is deleted or if part of the keyRange data is deleted, should we throw an error event? It seems reasonable to me. Let us know what you think. Israel
