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

On Fri, Mar 2, 2012 at 10:33 AM, Israel Hilerio <israelh@microsoft.com>wrote:

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

+1 to each of Israel's responses about the 5 proposals.


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

If it starts out as an empty list, why would we change it to null?  Either
way, no strong opinion here.


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