[indexeddb] Client API state after calling deleteIndex and deleteObjectStore

Resending with [indexeddb] heading!
------------

What should be the client state after a deleteIndex is called?
For example looking at the code below:

1. var index = objStore.index(indexName); 2. objStore.deleteIndex(indexName); 3. try {
4.       index.openCursor().onerror = function (e) { log("failed to open cursor"); }
5. } catch (ex) {
6.      log ("failed to call openCursor");
7. }

Similar to our previous conversation around transaction.abort, it seems that we would want to keep some knowledge on the client that the index was deleted at line #2 and therefore, line #4 will throw an exception that will be handled by line #6.  In this case, the onerror handler at line #4 will never be executed.

Do you agree?

Would it be good enough to just throw an UNKNOWN_ERR or we could create a new error code for this (e.g. CALLER_ERR or OBJECT_ERR).

Also, what should happen to deleteObjectStore when it is called in a similar situation:

1. var objStore = db.createObjectStore(osName, {keyPath: "name"}); 2. db.deleteObjectStore(osName); 3. try {
4.     objStore.index(indexName);
5. } catch (ex) {
6.     Log ("failed to call index");
7. }

I would also expect us to keep knowledge on the client that the objStore was deleted at line #2 and therefore not allow line #4 from queuing up a request but fail fast with an exception.  We could throw the same exception as the example above.

Do you agree?

Israel

Received on Wednesday, 13 July 2011 18:46:20 UTC