- 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