Re: [IndexedDB] Client API state after calling deleteIndex and deleteObjectStore

On Wed, Jul 13, 2011 at 11:39 AM, Israel Hilerio <israelh@microsoft.com> wrote:
> 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?

Yes! I do think we need to modify the spec to specify this.

> 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).

I would say NOT_ALLOWED_ERR or NOT_FOUND_ERR would be ok for this case.

> 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?

Yup. Seems identical to the situation you described above.

By the way, I assume this is only relevant during VERSION_CHANGE
transactions, right?

Another tricky situation is what to do with code like

1. var index = objStore.index(indexName);
2. req = index.get(2);
3. req.onsuccess = function() { log("didn't fail, value is" + req.result) };
4. req.onerror = function() { log("error was fired") };
5. objStore.deleteIndex(indexName);

I don't feel strongly what should happen. From an implementation point
of view it might be easy either way. In fact I think in the Gecko
implementation it might be easier to the request succeed and deliver
the same data as if the index hadn't been deleted, than to let it
fail. This is because all requests run on the same database thread (in
order to ensure that they run in the proper order), and so by the time
the index is deleted, we have already read data out from it.

>From a user point of view it might be slightly more useful if the
request succeeds, but it also seems quite ok to require that people
don't delete an index or objectStore unless they don't expect to get
more data from it.

/ Jonas

Received on Wednesday, 13 July 2011 21:10:13 UTC