W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Sat, 3 Dec 2011 21:24:54 -0800
Message-ID: <CA+c2ei9HttK5_5GrZKXxtMsSNj8_WcXE148uTszzXzeA7Nu1=A@mail.gmail.com>
To: Israel Hilerio <israelh@microsoft.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>, Adam Herchenroether <aherchen@microsoft.com>, Jim Wordelman <jaword@microsoft.com>
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
Received on Sunday, 4 December 2011 05:25:52 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT