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

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

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

Received on Friday, 2 March 2012 15:27:45 UTC