On Wednesday, December 07, 2011 3:45 PM, Jonas Sicking wrote: >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 Since the close method is not executed immeditely, my assumption was that it wouldn't have an impact on the VERSION_CHANGE transaction. Therefore, whatever values where committed as part of the VERSION_CHANGE will remain there after the db was closed. Israel
