- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 7 Dec 2011 15:45:10 -0800
- To: Israel Hilerio <israelh@microsoft.com>
- Cc: Adam Herchenroether <aherchen@microsoft.com>, Victor Ngo <vicngo@microsoft.com>, Jim Wordelman <jaword@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Wed, Dec 7, 2011 at 3:15 PM, Israel Hilerio <israelh@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 <israelh@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 >> >> <israelh@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
Received on Wednesday, 7 December 2011 23:46:15 UTC