Microsoft requested .version should be set to 'undefined' before firing the "abort" event in a recent thread.

So the question also applies in the following situation

var db;
var request = indexedDB.open(name, 1);
request.onupgradeneeded = function() {
  db = request.result;
  trans = request.transaction;
  trans.onabort = function() {
    alert("in onabort: " + db.version);
  }
  throw "STOP";
}
request.onerror = function() {
  alert("in onerror: " + db.version);
}

I'd rather not set the version to a non-integer value. I.e. I'd like for the sake of simplicity to keep the type of .version to simply be a non-nullable long long.

The only way we get to the onupgrade needed when the version is 1 is when there is no existing DB in the system.  The reason is that we are not allowed to pass in a version of 0 to the open API and versions are unsigned long long values.

Therefore, if we fail inside the onupgradeneeded handler, I would expect the database version to be undefined. Thus, alerting the developer that the database creation failed.  The reason for the undefined is that no new version existed before the open API was called.  This will keep things consistent with our request.

I understand we internally start with a 0 value for version when the db is created, but I don't believe we want to expose that value to developers.

Jonas, ignore my last request, I was answering the wrong thread.

What do you then suggest we should surface as the value of version if the initial creation of the database failes?  Are you suggesting we surface the 0 value and explain developers that if you get this value things went wrong?

Added step 9.5 to VERSION_CHANGE transaction steps, including table of default values for IDBDatabase attributes.

Thanks for the bug.

Eliot

The change made here is a bit unclear.

The text says "If the transaction is aborted and there is an existing database, the values remain unchanged".

There's two things that are unclear here. By "database" you mean the IDBDatabase(Sync) instance, right? Not the on-file database. I think we should clarify that.

Second, does "remain unchanged" mean unchanged compared to the on-disk values, or unchanged based on the values on the IDBDatabase instance before the transaction was aborted?


Almost the same questions also applies to the text says that if the VERSION_CHANGE transaction used to create a database is aborted, that "the database will remain in the system with the default attributes".

Is "database" referring to the on-disk database or the IDBDatabase instance? I would have assumed that the on-disk database is simply deleted if the transaction that created it is aborted.


I think I would prefer to not have any special treatment for VERSION_CHANGE transactions that create a database vs. ones that just upgrade the version number. This seems simplest from an implementation point of view.


Also, there's the minor nit that aborting can happen outside of the upgradeneeded event handler too since the transaction can span multiple success and error events too.


I would recommend something like the following text for step 9.5:

If for any reason the VERSION_CHANGE transaction is aborted the IDBDatabase instance which represents <var>connection</var> will remain unchanged. I.e. it's <code>name</code>, <code>version</code> and <code>objectStoreNames</code> properties will remain the value they were before the transaction was aborted.


(Note that objectStoreNames per the IDL is never null, though it can be an empty list).

I made the suggested change in today's Editor's draft.

Actually, this is still all sorts of wrong.

The text for the individual properties still say that they remain unchanged, whereas in reality it seemed like we wanted to say that they do change value when the transaction is aborted.

And step 9.5 of "versionchange transaction steps" still says that the properties will "remain unchanged".

And it seems very out-of-place to say what the "default values" are when there's no text to tie in to the default values.

And I believe there was agreement on the list to revert to an empty list, rather than null, for objectStoreNames.

Sorry guys, but I think this still needs more work :(

Section 4.9 Steps for aborting a "versionchange" transaction was added in the Editor's Draft of 7 May.