RE: [indexeddb] Bug#14404 https://www.w3.org/Bugs/Public/show_bug.cgi?id=14404

On Wednesday, December 07, 2011 3:45 PM, Jonas Sicking wrote:
>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

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

Received on Thursday, 8 December 2011 00:08:28 UTC