Deletion does not cancel or wait for background processing

[daleharvey]

I commented out all but 2 of the basic tests for PouchDB, 'create a pouch' and 'delete a pouch'

If I introduce a timeout then all is good, but run sequentially straight after each other they fail, it looks like the problem is the __createIndex 'background process' still runs after the database is deleted. I can definitely see calls to __createIndex after the deleteDatabase code has started running, as far as I can tell the deletion code beats the createIndex code and createIndex gets an unexpected empty table

Funnily enough I found the same problem in the chrome implementation of indexedDB

https://code.google.com/p/chromium/issues/detail?id=136400

[daleharvey]

I expect that fixing this by cancelling the queue or adding a new transaction manager will be crazy hard, what about if was waited for the objectStore creation to finish before calling the onsuccess of openDatabase

[daleharvey]

So I looked a bit more into this, each operation in the upgradeneeded request is creating a seperate transaction for each request, quite why I havent figured out (the createIndex requests have to wait for the createobjectstore request to complete, so not surprised they are seperate, but seems like the createObjectStore requests should be a single transaction)

I added a basic refcount so we waited for all createObjectStore + createIndex before firing

https://github.com/axemclion/IndexedDBShim/blob/master/src/shimIndexedDB.js#L70

It fixed my issue and I was able to run the create pouch + delete pouch in succession with them both passing. The way I did it was kinda nasty and broke some stuff later, I might be able to clean it up but chances are there is a better way to do what I want, any ideas?

[axemclion]

This was one of the things I always wanted to fix with the shim. The problem is - delete is a sync operation, and it gets complex when multiple tabs are open, the ref-count mechanism may not work. I was looking at using something like session storage for sharing this info across tabs, but have not got to that yet. I think checking for ref-count and using the flag is a good idea - that is what the facebook implementation does.

[daleharvey]

lol, when I used the facebook shim (with your patch) I get the same problem as I do when I added the refcount stuff in your shim (first 2 tests run fine, 'add a doc' stalls), this is going to be fun :)

[JamesMessinger]

Can you please try this again with the latest version of IndexedDBShim? We've fixed a ton of bugs recently, including many intricate timing bugs like this one.