W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

[indexeddb] Client API state after calling deleteIndex and deleteObjectStore

From: Israel Hilerio <israelh@microsoft.com>
Date: Wed, 13 Jul 2011 18:45:50 +0000
To: "public-webapps@w3.org" <public-webapps@w3.org>
CC: David Sheldon <dsheldon@microsoft.com>
Message-ID: <F695AF7AA77CC745A271AD0F61BBC61E3D1930E3@TK5EX14MBXC119.redmond.corp.microsoft.com>
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?

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:22 UTC