W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

IndexedDB: What happens when versionchange transaction is aborted?

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 2 Mar 2012 04:35:19 +0100
Message-ID: <CA+c2ei_E5CftcgTHa2z=UYz_FzGS090fcUg79TtQ1Qx1-SgYrA@mail.gmail.com>
To: Webapps WG <public-webapps@w3.org>
Hi All,

While editing the spec just now I came across something that I didn't
quite understand. In section 4.8 ""versionchange" transaction steps"
step 9 says:

"If for any reason the "versionchange" transaction is aborted while in
the onupgradeneeded event handler while the database is being created
for the first time, the database will remain in the system with the
default attributes. If the transaction is aborted and there is an
existing database, the values remain unchanged. The default attributes
for the IDBDatabase are:"

And then has a table.

My recollection was that this text was added as a result of
discussions of what the IDBDatabase.objectStoreNames/version/name
properties should return after a "versionchange" transaction is
aborted.

However the text is ambiguous in a few ways which makes me not sure
what to do in the Firefox implementation.

First of all, the text seems to use the word "database" to mean two
different things. In "the database is being created for the first
time" I think database is intended to refer to the on-disk database
file. In "the database will remain in the system" I think database
intends to refer to the in-memory IDBDatabase instance. Or is the text
really intending to say that we should keep the on-disk database file
even if the transaction which creates the database is aborted?

Second, it seems to treat newly created databases different from ones
that are upgraded. It says that newly created database should get
their default value, with version set to 0 and objectStoreNames being
null. In other words it calls for these properties to be reverted to
the value they had before the "versionchange" event fired. However
existing database should "remain unchanged" which I interpret to mean
that they should retain the value they had at the time when the
transaction was aborted.

I really don't care that much what behavior we have here since it's
unlikely that anyone is going to look at these properties after a
"versionchange" transaction is aborted and thus the open request
fails. But I think we should be consistent and treat newly opened
databases the same as we treat newly upgraded databases. In both
situations we can one of the following:

1. Revert properties to the value they had when the version-change
transaction started
2. Revert properties to the value they had when the right after the
version-change transaction started (i.e. only the .version property is
changed)
3. Keep properties as they were when the transaction was aborted (this
is what we do for close())
4. Make properties throw
5. Make properties return null

Also, technically objectStoreNames starts out as an empty list, not
null as the table currently claims. But we can of course still revert
it to null if we go with option 1 or 2.

I don't really care which option we choose though 4 and 5 sounds
annoying for users and doesn't seem any easier to implement. I'd
personally lean towards 3. It seems like the current text is aiming
for 1 or 3 but I can't say with certainty.

I'm happy to edit this into the spec as soon as we get agreement on
what behavior we want.

/ Jonas
Received on Friday, 2 March 2012 03:36:16 GMT

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