[Bug 18551] New: [IndexedDB] Ambiguity about operations preceding a failed createIndex.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18551

           Summary: [IndexedDB] Ambiguity about operations preceding a
                    failed createIndex.
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Indexed Database API
        AssignedTo: dave.null@w3.org
        ReportedBy: alecflett@chromium.org
         QAContact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org


jsbell and I have been discussing a possible ambiguity in the IndexedDB spec
w.r.t. error handling around createIndex calls.


In particular, createIndex() is supposed to behave somewhat synchronously in
that calling:


the implementation must create a newindex and return an IDBIndex object
representing it.

so that this is reasonable:
objectStore.createIndex('foo',...)
objectStore.put(...)
objectStore.index('foo').get(...)

But at the same time createIndex() behaves somewhat asynchrnously - while the
metadata for the index needs to be there immediately, the actual indexing data
doesn't have to:

> In some implementations it's possible for the implementation to asynchronously run into problems creating the index after the createIndex function has returned. For example in implementations where metadata about the newly created index is queued up to be inserted into the database asynchronously, or where the implementation might need to ask the user for permission for quota reasons. Such implementations must still create and return an IDBIndex object. Instead, once the implementation realizes that creating the index has failed, it must abort the transaction using thesteps for aborting a transaction using the appropriate error as error parameter. 

The issue in question is how to handle this:

objectStore.put({"foo": 1, "message": "hello"});
req = objectStore.put({"foo": 1, "message": "goodbye"});
objectStore.createIndex("foo", "foo", {unique: true});    // will fail
asynchronously

The question is, should req's onerror fire or not? 

>From discussion on the list, I think most folks agree that both put()'s should
succeed, but the spec needs to be clear on this.


A suggested clarification, but I'm sure it could be worded better.

In some implementations it's possible for the implementation to asynchronously
run into problems creating the index [data] after the createIndex function has
returned. For example in implementations where [indexing data about existing
objects in the database] is queued up to be inserted into the database
asynchronously, or where the implementation might need to ask the user for
permission for quota reasons. Instead, once the implementation realizes that
creating the objectStore has failed, it must abort the transaction using the
steps for aborting a transaction using the appropriate error as error
parameter. [If asynchronous write operations within the same transaction
precede the createIndex, and they are the cause of the failure to create the
index, they should not fail for this reason.] For example if creating the index
failed due to quota reasons, QuotaError must be used as error and if the index
can't be created due to unique constraints, ConstraintError must be used as
error [and preceding requests which created these constraint violations should
not fail.]

-- 
Configure bugmail: https://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 Monday, 13 August 2012 20:36:28 UTC