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.
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 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? Israel On Mon, Tuesday, May 03, 2011 9:07 PM, Jeremy Orlow wrote: > Undefined is also the return value for void functions. The result is > essentially the return value of our async methods. And in most cases, the > behavior of each async method is just a transformation of the sync method and > vice versa. So my thinking is that it should stay as it is. > > J > On Mon, May 2, 2011 at 11:22 PM, Israel Hilerio <isra...@microsoft.com> wrote: > > After calling the clear() method on IDBObjectStore, the result of the > > IDBRequest is set to undefined according to the "steps for clearing an > > object store". >> > > However, the result property in IDBRequest says that the result value is > > undefined when the request results in an error: "This is undefined when the > > request resulted in an error." >> > > In IE, we've been using undefined to signal properties that are not > > available to developers and null to signal unassigned values. It seems > > that null would be a better result value when the object store has been > > cleared. >> > > This would follow the same pattern we use in the deleteDatabase method > > where we return a null value for the result of the IDBRequest: "If the > > steps above are successful, the implementation must set the result of the > > request to null and fire a success event at the request." >> > > What do you think? >> > > Israel
