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

This is how I've understood it as well, and I'm very OK with it :)

Getting it clear in like that would be a win.

--

Sent from my N9, excuse the top posting



On 03.05.12 01:32 Jonas Sicking 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).


I don't think it particularly matters what which solution we chose,
I.e. I don't think either solution is better for authors. But
whichever solution we choose it should be clearly defined in the spec.


/ Jonas