Great, I believe we have consensus. This is the summary of changes we've discussed plus one question/clarification:
1. IDBDatabase.deleteObjectStore should change to: * void deleteObjectStore (in DOMString name) raises (IDBDatabaseException); 2. IDBDatabase.createObjectStore and IDBDatabase.removeObjectStore will act synchronously and modify IDBDatabase.objectStoreNames. 3. IDBObjectStore.createIndex and IDBObjectStore.deleteIndex will act synchronously and modify IDBObjectStore.indexNames. 4. The result value on the IDBRequest returned by IDBFactory.deleteDatabase will be set to undefined when the function executes correctly. 5. The result value on the IDBRequest returned by IDBObjectStore.clear will be set to undefined when the function executes correctly. 6. IDBCursorSync.advance should change to: * boolean advance (in int count); Returns true if it iterates to a valid position and false if it iterates off of the end. Also, the result value on the IDBRequest returned by IDBCursor.advance should be the cursor itself if it iterates to a valid position, or null if it iterates off of the end. Additional questions ----------------------------- 7. I don't see in the spec that IDBObjectStoreSync.delete and IDBCursorSync.delete currently return true/false. I see them both as void functions. If it was previously agreed to have these functions return Booleans, we should update the spec to reflect it. 8. Assuming we update the spec with the change above, I believe you're also suggesting we make the following change: * The result value on the IDBRequest returned by IDBObjectStore.delete and IDBCursor.delete holds true or false depending on if the value existed or not. If we feel good about these changes, I can work with Eliot to update the spec. Let me know. Israel On Wed, May 4, 2011 at 1:35 PM, Jonas Sicking wrote: > On Wed, May 4, 2011 at 11:04 AM, Israel Hilerio <isra...@microsoft.com> > wrote: > > If that is the case we need to ensure that the async implementations for > deleteDatabase and deleteObjectStore have consistent results on their > IDBRequest. deleteDatabase stipulates that the result of the request is null > and deleteObjectStore stipulates that the result of the request is > undefined. Using your logic they both should return undefined results. > > Yes. I think that deleteDatabase should return undefined. > deleteObjectStore should be a synchronous method (per other thread) > returning void and so no return value would need to be defined. > > > Furthermore, we should be using this pattern everywhere there is an async > function that returns an IDB Request and there is a counterpart sync void > function. That would mean that for each of the following functions the result > of the request should be undefined: > > * IDBFactorySync.deleteDatabase --> IDBFactory.deleteDatabase > > * IDBDatabaseSync.deleteObjectStore --> IDBDatabase.deleteObjectStore > > * IDBObjectStoreSync.delete --> IDBObjectStore.delete > > * IDBObjectStoreSync.clear --> IDBObjectStore.clear > > * IDBCursorSync.delete --> IDBCursor.delete > > IDBObjectStore(Sync).delete and IDBCursor(Sync).delete currently return > true/false depending on if the value existed or not. I think that is useful > and > should remain. > > For the other methods I agree that they should return void and so have no > return value at all (or have .result set to undefined in the asynchronous > versions). > > Potentially deleteDatabase could return true/false just like objectStore and > cursors. However I can't really come up with any use cases for this so it > might > be better to stick with using void/undefined for now. We can always add a > return value later if a use case arises. > > > These functions are okay. They are both void functions: > > * IDBObjectStoreSync.deleteIndex --> IDBObjectStore.deleteIndex > > * IDBDatabaseSync.close --> IDBDatabase.close > > * IDBCursorSync.advance --> IDBCursor.advance > > * IDBTransactionSync.abort --> IDBTransaction.abort > > > > This one should be okay to because because it has a callback: > > * IDBDatabaseSync.transaction(...) > > > > Do you agree? > > Largely yes. > > Though looking at cursor.advance, it should behave like cursor.continue as it > provides basically the same functionality. This means that the asynchronous > version should return the cursor itself if it iterates to a valid position, > or null > if it iterates off of the end. The synchronous version should return true if > it > iterates to a valid position and false if it iterates off of the end. I think > there > are some bugs in the spec currently, both for cursor.advance and > cursor.continue. > > Other than that I think you're spot on. > > / Jonas
