On Wed, Dec 7, 2011 at 3:15 PM, Israel Hilerio <isra...@microsoft.com> wrote: > On Wednesday, December 07, 2011 2:48 PM, Jonas Sicking wrote: >> On Wed, Dec 7, 2011 at 2:27 PM, Israel Hilerio <isra...@microsoft.com> >> wrote: >> > On Saturday, December 03, 2011 9:25 PM, Jonas Sicking wrote: >> >> On Thu, Dec 1, 2011 at 2:51 PM, Israel Hilerio >> >> <isra...@microsoft.com> >> >> 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. >> >> That's fine with me yeah. > > Cool! > >> >> And what about when .close() is called during the VERSION_CHANGE >> transaction? >> >> / Jonas > > For us, when the close method is invoked inside the onupgradeneeded handler, > the db is immediately marked to be closed but it is not immediately closed. > The db is closed at a later time when no one else is interacting with it. > Therefore, closing the db inside the onupgradeneeded handler doesn't do > anything to the current transaction.
Yes, that's required by spec. The question is, what does the database-object's .name, .version and .objectStoreNames properties return after the transaction is comitted if the database was closed? / Jonas
