On Saturday, December 03, 2011 9:25 PM, Jonas Sicking wrote: > On Thu, Dec 1, 2011 at 2:51 PM, Israel Hilerio <[email protected]> > wrote: > > Jonas, > > > > Since you believe we should keep the values of version as a non-nullable > long long, what should the value of version be during the first run/creation > if > the transaction is aborted? Should it be 0 (I don't believe we want version to > be a negative number)? > > I realized the other day that the question also applies to what should > db.objectStoreNames return? It makes sense that whatever changes we > make to .version we'd also make to .objectStoreNames. Do we revert it to > the value it had before the transaction was started? Do we throw? > Do we return null/0? > > Ultimately I feel like there really is very little reason for someone to use > these properties if the VERSION_CHANGE transaction fails, and so I'm > leaning more towards that we should do whatever is easy to implement. > > So what I suggest is that we do the same thing as for .close(). I.e. > we leave the values untouched. This seems not only easy to implement but > also is consistent with .close(). > > / Jonas
What about this behavior to summarize all ideas: Once the onupgradeneeded handler is called, the database is automatically created. If the VERSION_CHANGE transaction is aborted for any reason when the database is being created for the first time, the database will remain in the system with the following attributes: name="assigned db name", version = 0, and objectStoresNames = null. Do you agree? Israel
