RE: IndexedDB: What happens when versionchange transaction is aborted?

On Friday, March 02, 2012 7:27 AM, Jonas Sicking wrote:
> On Fri, Mar 2, 2012 at 4:35 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> > 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?
> >

As I recall, we had talked about keeping the initial DB version (i.e. 0) even if the versionchange transaction was aborted [1].  The reason was that a version of 0 is something that can only be generated internally and would signal the initial creation state of the db.  However, we didn't want to store any more information about the db at that point because the transaction was cancelled.  This enabled us to reject the developer changes but keep the internal processing.  This would allow developers to retry their transactions with a version of 1 and not have any side effects.

> > 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.

The intent was to ensure that db versionchange transactions on new or existing dbs would retain their pre-transaction state [1].  That was the reason, we defined the table to capture the pre-transaction state of non-existent dbs.  This was an intent to keep them consistent.

> >
> > 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 

I like this one [1].  This approach allows the same version to be reused in the correct/intended way.

> > 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)

I believe this approach would prevent the same version from being used in the correct/intended way.

> > 3. Keep properties as they were when the transaction was aborted (this
> > is what we do for close()) 

I believe having residual values could lead to potential side effects.  I like it better to not have any residual information from the failed transaction.

> > 4. Make properties throw 5. Make properties
> > return null
> >

I believe there are some tooling scenarios in which it might be useful to access the properties.

> > 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 would like for us to choose option 1 and therefore, null seems reasonable.

> >
> > 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 thought option 1 was what we had agree on [1].

> > I'm happy to edit this into the spec as soon as we get agreement on
> > what behavior we want.
> 
> I knew that I had a feeling of déjà vu when I wrote this email. I wrote a very
> similar comment about a month ago here:
> 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14404#c6
> 
> / Jonas
> 

Israel
[1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1415.html

Received on Friday, 2 March 2012 18:34:55 UTC