This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10052 - Specify setVersion details
Summary: Specify setVersion details
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Indexed Database API (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Andrei Popescu
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2010-06-29 20:37 UTC by Jonas Sicking (Not reading bugmail)
Modified: 2010-08-09 22:25 UTC (History)
6 users (show)

See Also:


Description Jonas Sicking (Not reading bugmail) 2010-06-29 20:37:09 UTC
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,
                                   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;

Comment 1 Jeremy Orlow 2010-07-02 07:20:53 UTC
Sounds good.
Comment 2 Jonas Sicking (Not reading bugmail) 2010-07-12 19:24:15 UTC
Taking this bug. See [1] for pros and cons of the various proposals

Comment 3 Andrei Popescu 2010-08-04 13:57:43 UTC
Will send a patch to fix this and then we can publish another working draft.
Comment 4 Andrei Popescu 2010-08-09 22:25:09 UTC
Fixed in