- From: Victor Costan <notifications@github.com>
- Date: Sun, 20 Aug 2017 22:51:45 -0700
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/IndexedDB/issues/31/323652327@github.com>
I'm starting to think that I made a mistake by reusing the IDBRequest mechanism, and the API would be better served by a Promise. I'd rather not invoke the algorithms related to queuing an IDB request, so we have complete freedom in specifying (the lack of) ordering guarantees. @beidson -- On your question about why implementations would need to block, I can imagine an implementation where all the IDB metadata for an origin lives in a single table. `versionchange` would require a write lock on the table, and `getAllDatabases` would require a read lock on the table. Can we agree to spec the method in such a way that an implementation that needs to block on `versionchange` (i.e. not respond until the `versionchange` completes) can do so, and an implementation that doesn't need to block is free to return inconsistent data? If I'm understanding correctly, it seems like Firefox would fall in the first category, and WebKit + Blink would fall in the second category. I think we'll need some sort of guarantees, to be able to write WPT tests for this feature. My proposal (roughly the same as before), which I think is a subset of what WebKit offers, is: 1) If `getAllDatabases` is called at a quiet time (when no transactions are active) for the origin, it will see the result of all transactions that occurred before the call. 2) Otherwise, `getAllDatabases` will get a result that may reflect any subset of committed or uncommitted transactions since the last quiet time for the origin. @bevis-tseng -- Regarding your comment about use cases and rushing, I'll share my thoughts, and end with a question. I think we had `webkitGetDatabaseNames` in Blink and WebKit for a few years now. Based on the comments we got when removing it, developers were using it for debugging (list all databases) and for cleanup (remove all databases for the origin that don't match the expected state). Chrome's DevTools also uses the same API internally for IndexedDB inspection. For whatever it's worth, I don't recall receiving a single developer complaint about the lack of consistency guarantees. Are there any use cases you'd like to explore, other than the two listed above? Is there any other information that make you comfortable reaching a consensus about this API? Thank you very much for your comments, everyone! IndexedDB is subtle, and thinking about it can be draining. I am grateful for your replies! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/IndexedDB/issues/31#issuecomment-323652327
Received on Monday, 21 August 2017 05:52:07 UTC