- From: Israel Hilerio <israelh@microsoft.com>
- Date: Wed, 13 Jul 2011 18:39:08 +0000
- To: "public-webapps@w3.org" <public-webapps@w3.org>
- CC: David Sheldon <dsheldon@microsoft.com>
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:39:37 UTC