[Bug 10052] New: Specify setVersion details

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10052

           Summary: Specify setVersion details
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
        AssignedTo: nikunj.mehta@oracle.com
        ReportedBy: jonas@sicking.cc
         QAContact: member-webapi-cvs@w3.org
                CC: mike@w3.org, public-webapps@w3.org


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

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Tuesday, 29 June 2010 20:37:11 UTC