Bug 14404 - Version of an IDBDatabase from an aborted version change transaction needs to be specified
Summary: Version of an IDBDatabase from an aborted version change transaction needs to...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Eliot Graff
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-07 17:23 UTC by Kyle Huey
Modified: 2012-05-08 15:09 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle Huey 2011-10-07 17:23:17 UTC
Consider the following for a database that does not already exist:

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

What should the version be here?  The new version?  The old version?  Something else?  By my reading of the spec, since the version is not supposed to change throughout the lifetime of an IDBDatabase, the answer is the new version, which seems quite unintuitive since the upgrade failed.
Comment 1 Jonas Sicking 2011-10-07 17:27:35 UTC
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);
}
Comment 2 Jonas Sicking 2011-11-02 15:57:25 UTC
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.
Comment 3 Israel Hilerio [MSFT] 2011-11-30 21:19:35 UTC
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.
Comment 4 Israel Hilerio [MSFT] 2011-11-30 21:23:52 UTC
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?
Comment 5 Eliot Graff 2011-12-27 22:04:37 UTC
Added step 9.5 to VERSION_CHANGE transaction steps, including table of default values for IDBDatabase attributes.

Thanks for the bug.

Eliot
Comment 6 Jonas Sicking 2012-01-24 03:52:24 UTC
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).
Comment 7 Eliot Graff 2012-03-09 20:51:14 UTC
I made the suggested change in today's Editor's draft.
Comment 8 Jonas Sicking 2012-03-26 11:52:41 UTC
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 :(
Comment 9 Eliot Graff 2012-05-08 15:09:44 UTC
Section 4.9 Steps for aborting a "versionchange" transaction was added in the Editor's Draft of 7 May.