Re: [IndexedDB] Bug 14404: What happens when a versionchange transaction is aborted?

On Thu, May 3, 2012 at 1:30 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> Hi All,
>
> The issue of bug 14404 came up at the WebApps face-to-face today. I
> believe it's now the only remaining non-editorial bug. Since we've
> tried to fix this bug a couple of times in the spec already, but it
> still remains confusing/ambigious, I wanted to re-iterate what I
> believe we had decided on the list already to make sure that we're all
> on the same page:
>
> Please note that in all cases where I say "reverted", it means that
> the properties on the JS-object instances are actually *changed*.
>
> When a versionchange transaction is aborted, the following actions
> will be taken:
>
> IDBTransaction.name is not modified at all. I.e. even if is is a
> transaction used to create a new database, and thus there is no
> on-disk database, IDBTransaction.name remains as it was.
>
> IDBTransaction.version will be reverted to the version the on-disk
> database had before the transaction was started. If the versionchange
> transaction was started because the database was newly created, this
> means reverting it to version 0, if it was started in response to a
> version upgrade, this means reverting to the version it had before the
> transaction was started. Incidentally, this is the only time that the
> IDBTransaction.version property ever changes value on a given
> IDBTransaction instance.
>
> IDBTransaction.objectStoreNames is reverted to the list of names that
> it had before the transaction was started. If the versionchange
> transaction was started because the database was newly created, this
> means reverting it to an empty list, if it was started in response to
> a version upgrade, this means reverting to the list of object store
> names it had before the transaction was started.
>
> IDBObjectStore.indexNames for each object store is reverted to the
> list of names that it had before the transaction was started. Note
> that while you can't get to object stores using the
> transaction.objectStore function after a transaction is aborted, the
> page might still have references to objec store instances and so
> IDBObjectStore.indexNames can still be accessed. This means that for
> any object store which was created by the transaction, the list is
> reverted to an empty list. For any object store which existed before
> the transaction was started, it means reverting to the list of index
> names it had before the transaction was started. For any object store
> which was deleted during the transaction, the list of names is still
> reverted to the list it had before the transaction was started, which
> potentially is a non-empty list.
>
> (We could of course make an exception for deleted objectStore and
> define that their .indexNames property remains empty. Either way we
> should explicitly call it out).
>
>
> The alternative is that when a versionchange transaction is aborted,
> the IDBTransaction.name/IDBTransaction.objectStoreNames/IDBObjectStore.indexNames
> properties all remain the value that they have when the transaction is
> aborted. But last we talked about this Google, Microsoft and Opera
> preferred the other solution (at least that's how I understood it).

Oh, and I should add that no matter what solution with go with (i.e.
whether we change the properties back to the values they had before
the transaction, or if we leave them as they were at the time when the
transaction is aborted), we should *of course* on disk revert any
changes that were done to the database.

The question is only what we should do to the properties of the
in-memory JS objects.

/ Jonas

Received on Thursday, 3 May 2012 22:30:50 UTC