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

On Wed, Jul 13, 2011 at 3:02 PM, Israel Hilerio <israelh@microsoft.com> wrote:
> On Wednesday, July 13, 2011 2:02 PM, Jonas Sicking wrote:
>> 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
>
> Great!  Yes, this is only relevant to VERSION_CHANGE transactions.
>
> I definitely see what you mean in your example.  Like you said, it seems to depend where in the processing cycle those success or error events are as whether the developer will receive them or not.  I also agree with your point, developers shouldn't be deleting indexes or objectStores if they are expecting some results from them.

Sorry, that's not what I meant to say.

>From an implementation point of view, at least in gecko, not taking
this problem into account at all will result in the success handler on
line 3 executing just as if the deleteIndex call never happened. This
is because we do all our database work on a separate thread, but all
database work happens on that one thread. That means that that thread
will first do the read from the index, then delete the index. I would
*guess* that the same will happen in other implementations, but I'm
very interested in feedback from other implementations on this.

>From a user point of view, it seems more useful to have the request
succeed. However, I think this is a weird usage pattern, and that if
you want to read from an index or objectStore and then delete it,
there are other ways to do that. Hence I think user arguments should
take a lower precedence than implementation arguments in this case.

So *if* it is the fact that it's just as easy, or even easier, to have
the request succeed in other implementations, then I think that's the
behavior we should go with.

Hope that makes makes it clearer? I'm definitely open to other suggestions.

/ Jonas

Received on Wednesday, 13 July 2011 23:43:54 UTC