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

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.

And what about when .close() is called during the VERSION_CHANGE transaction?

/ Jonas

Received on Wednesday, 7 December 2011 22:49:08 UTC