In the thread started at [1] there were some discussions about how setVersion should work. It seems like there was consensus (at least among the participants in the thread) for the following behavior

When setVersion(X) is called, perform the following steps:
1. Create a IDBRequest object, /request/.

2. If there are no other IDBDatabase objects open to the same database, skip to next step.

Otherwise, asynchronously fire a "versionchange" event targeted at those IDBDatabase objects. The "versionchange" event implements a IDBVersionChangeEvent interface defined below, and has the 'version' property is set to X. Also asynchronously fire a 'blocked' event on /request/.

3. Return the /request/ object and finish the setVersion call.

4. Once all other IDBDatabase objects are closed, initiate a transaction with mode VERSION_CHANGE. As long as this transaction is open, no other IDBDatabase objects can be opened to the same database.

5. Fire a 'success' event on /request/ with .transaction set to the transaction created in step 5.

6. Follow the normal steps for transactions (i.e. allow requests to be placed, etc)



When createObjectStore/createIndex/removeObjectStore/removeIndex is called, perform the following steps:

1. If we're not currently firing a 'success' event on a VERSION_CHANGE transaction, throw an exception. I.e. only 'success' event handlers inside a VERSION_CHANGE transaction can make schema related modifications. However note that it's not just the 'success' event from the original setVersion call that is allowed to make schema changes. You can also make them from, for example, the success event fired after a 'get' request, as long as that 'get' request was made on a VERSION_CHANGE transaction.

2. If removeObjectStore or removeIndex is called, remove the relevant object if it exists and return from the function. If it doesn't exist, do nothing and return from the function.

3. If createObjectStore/createIndex is called with invalid parameters, such as an invalid keyPath, throw an exception. Likewise, if the objectStore or index already exists, throw an exception.

4. Create the requested object and add it to the database. Return the newly created object and return from the function.



Add a .close() function to IDBDatabase. When the function is called, perform the following steps:

1. Set a internal /closePending/ flag to true. If .transaction is called, and /closePending/ is true, an exception is thrown (or should we just make .transaction return null?)

2. Once all pending transactions are finished, the IDBDatabase is fully closed. This unblocks any pending setVersion calls made on other IDBDatabase objects connected to the same database.



IDL for related APIs:

IDBDatabase {
  ...
  IDBObjectStore createObjectStore(in DOMString name,
                                   [TreatNullAs=EmptyString]
                                   in optional DOMString keyPath,
                                   in optional boolean autoIncrement);
  readonly attribute bool closePending;
  void close();
  ...
};

IDBObjectStore {
  ...
  IDBIndex createIndex(in DOMString name, in DOMString keyPath,
                       in optional boolean unique);
  ...
};

interface IDBVersionChangeEvent : IDBEvent {
 readonly attribute string version;
};


[1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/1141.html