On Wed, Jul 13, 2011 at 3:02 PM, Israel Hilerio <[email protected]> wrote: > On Wednesday, July 13, 2011 2:02 PM, Jonas Sicking wrote: >> On Wed, Jul 13, 2011 at 11:39 AM, Israel Hilerio <[email protected]> >> 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
