5 ms·

What’s new in IndexedDB 2.0?

56 points by dwaxe 10y ago

jstclair 10y ago
No mentions of promises? Any reason to rev the spec without promises?
- bwindels 10y ago
  IIRC the main reason indexeddb does not use promises is because promises are required to reject/resolve asynchronously [1]. Indexeddb requires that you manipulate the object stores in a synchronous way from it's event handlers, so it can terminate the transaction after running the event handlers synchronously. It can't do this with promises that will run their resolve handler at best in the next microtask. It's been a while since I looked into this, but I remember this being my conclusion. 1: https://promisesaplus.com/#point-34 https://promisesaplus.com/#point-34
  - jstclair 10y ago
    I understand the transactional requirements but AFAIK most IDB operations are already async. Open for example: https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/open https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/... "The method returns an IDBOpenDBRequest object immediately, and performs the open operation asynchronously."
  - dumbmatter 10y ago
    That's actually not true in Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=457409 https://bugs.chromium.org/p/chromium/issues/detail?id=457409 although it's not clear if that is a bug in Chrome or in other browsers. It would be nice to have more clarity on that, or an explicit promise API like https://github.com/inexorabletash/indexeddb-promises https://github.com/inexorabletash/indexeddb-promises because until then it's really shitty to use - you have to constantly worry about cross-browser compatibility.
- coldtea 10y ago
  Not all operations are asynchronous.
- dumbmatter 10y ago
  Here's the discussion on promises: https://github.com/inexorabletash/indexeddb-promises https://github.com/inexorabletash/indexeddb-promises The 2.0 spec is just a bunch of minor changes. Promises will be a big change - although I would argue it's way more important than all this other stuff combined.
Achshar 10y ago
I still feel that the api is a lot more complicated than it has any right to be. WebSQL for example was nifty little thing that worked just fine as far as me as a dev is concerned. I realize there must have been considerable issues with it from implementation POV but IDB seems so much worse (to me at least).
- pilif 10y ago
  It wasn't so much of an implementation issue as it was politics around the spec that killed it: As WebSQL basically happened by just exposing a SQLite runtime to JS, there was never a clear spec of what WebSQL should support (no - "it just supports all that SQLite supports" is not good enough). And even if somebody went in and specified all of SQLite's features, then there would still be the issue that any accepted web standard needs two independent implementations, meaning that one of the browsers would have had to clean-room reimplement SQLite. And finally, there would be the question of what to do as SQLite involved. What would browsers do as SQLite gains features or changes behaviour? Keep the old version of SQLite around for JS? Freeze the whole browser on the old version of SQLite? I agree though that WebSQL was much more convenient and useful than IndexedDB.
  - egeozcan 10y ago
    IIRC, the idea was making IndexedDB low-level, giving way to the library authors to create something easier to use. I'm not sure if that ever happened.
    - tobltobs 10y ago
      Dexie.js [1] is doing that and is one of the most undervalued projects I work with. [1] http://dexie.org/ http://dexie.org/
    - robin_reala 10y ago
      PouchDB[1] sits on top of IndexDB (or WebSQL and other methods) and exposes a CouchDB-like interface. [1] https://pouchdb.com/ https://pouchdb.com/
amelius 10y ago
What happens if you access the database simultaneously from different browser tabs? Also, is there some eventing mechanism to push messages through the database between tabs?
- dumbmatter 10y ago
  What happens if you access the database simultaneously from different browser tabs? It works fine. Transactions prevent conflicts. And you can even do schema upgrades because there is built-in versioning, and it provides events to let you handle when a version change occurs in another tab. Also, is there some eventing mechanism to push messages through the database between tabs? No, you have to do that yourself.
- deno 10y ago
  > Also, is there some eventing mechanism to push messages through the database between tabs? http://caniuse.com/#feat=broadcastchannel http://caniuse.com/#feat=broadcastchannel
jakub_g 10y ago
The announcement made me check caniuse for IndexedDB support, and it turns out that Safari 10 finally has non-broken IndexedDB: http://caniuse.com/#feat=indexeddb http://caniuse.com/#feat=indexeddb https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_0.html https://developer.apple.com/library/content/releasenotes/Gen... https://github.com/localForage/localForage/issues/604#issuecomment-247335607 https://github.com/localForage/localForage/issues/604#issuec... https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26 https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26
- dumbmatter 10y ago
  Despite what some claim, Safari 10's IndexedDB is still quite broken, except possibly for some trivial cases (like if you only use one object store, or you don't use indexes): https://www.reddit.com/r/javascript/comments/545ylm/psa_indexeddb_on_safari_10_is_still_shitty/ https://www.reddit.com/r/javascript/comments/545ylm/psa_inde...
  - jakub_g 10y ago
    Good to know, thanks for sharing!
tuckerjt07 10y ago
I'm currently working on a Angular2 cache management, similar to Redis, wrapper for IDB and these features will help quite a bit with a few of the lower performance operations in my API.
ralusek 10y ago
If any of you are serious about using IndexedDB, please consider: https://github.com/google/lovefield https://github.com/google/lovefield Explanation here: https://www.youtube.com/watch?v=S1AUIq8GA1k https://www.youtube.com/watch?v=S1AUIq8GA1k

56 points by dwaxe 10y ago

jstclair 10y ago

No mentions of promises? Any reason to rev the spec without promises?

bwindels 10y ago
IIRC the main reason indexeddb does not use promises is because promises are required to reject/resolve asynchronously [1]. Indexeddb requires that you manipulate the object stores in a synchronous way from it's event handlers, so it can terminate the transaction after running the event handlers synchronously. It can't do this with promises that will run their resolve handler at best in the next microtask. It's been a while since I looked into this, but I remember this being my conclusion. 1: https://promisesaplus.com/#point-34 https://promisesaplus.com/#point-34
- jstclair 10y ago
  I understand the transactional requirements but AFAIK most IDB operations are already async. Open for example: https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/open https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/... "The method returns an IDBOpenDBRequest object immediately, and performs the open operation asynchronously."
- dumbmatter 10y ago
  That's actually not true in Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=457409 https://bugs.chromium.org/p/chromium/issues/detail?id=457409 although it's not clear if that is a bug in Chrome or in other browsers. It would be nice to have more clarity on that, or an explicit promise API like https://github.com/inexorabletash/indexeddb-promises https://github.com/inexorabletash/indexeddb-promises because until then it's really shitty to use - you have to constantly worry about cross-browser compatibility.
coldtea 10y ago
Not all operations are asynchronous.
dumbmatter 10y ago
Here's the discussion on promises: https://github.com/inexorabletash/indexeddb-promises https://github.com/inexorabletash/indexeddb-promises The 2.0 spec is just a bunch of minor changes. Promises will be a big change - although I would argue it's way more important than all this other stuff combined.

Achshar 10y ago

I still feel that the api is a lot more complicated than it has any right to be. WebSQL for example was nifty little thing that worked just fine as far as me as a dev is concerned. I realize there must have been considerable issues with it from implementation POV but IDB seems so much worse (to me at least).

pilif 10y ago
It wasn't so much of an implementation issue as it was politics around the spec that killed it: As WebSQL basically happened by just exposing a SQLite runtime to JS, there was never a clear spec of what WebSQL should support (no - "it just supports all that SQLite supports" is not good enough). And even if somebody went in and specified all of SQLite's features, then there would still be the issue that any accepted web standard needs two independent implementations, meaning that one of the browsers would have had to clean-room reimplement SQLite. And finally, there would be the question of what to do as SQLite involved. What would browsers do as SQLite gains features or changes behaviour? Keep the old version of SQLite around for JS? Freeze the whole browser on the old version of SQLite? I agree though that WebSQL was much more convenient and useful than IndexedDB.
- egeozcan 10y ago
  IIRC, the idea was making IndexedDB low-level, giving way to the library authors to create something easier to use. I'm not sure if that ever happened.
  - tobltobs 10y ago
    Dexie.js [1] is doing that and is one of the most undervalued projects I work with. [1] http://dexie.org/ http://dexie.org/
  - robin_reala 10y ago
    PouchDB[1] sits on top of IndexDB (or WebSQL and other methods) and exposes a CouchDB-like interface. [1] https://pouchdb.com/ https://pouchdb.com/

amelius 10y ago

What happens if you access the database simultaneously from different browser tabs? Also, is there some eventing mechanism to push messages through the database between tabs?

dumbmatter 10y ago
What happens if you access the database simultaneously from different browser tabs? It works fine. Transactions prevent conflicts. And you can even do schema upgrades because there is built-in versioning, and it provides events to let you handle when a version change occurs in another tab. Also, is there some eventing mechanism to push messages through the database between tabs? No, you have to do that yourself.
deno 10y ago
> Also, is there some eventing mechanism to push messages through the database between tabs? http://caniuse.com/#feat=broadcastchannel http://caniuse.com/#feat=broadcastchannel

jakub_g 10y ago

The announcement made me check caniuse for IndexedDB support, and it turns out that Safari 10 finally has non-broken IndexedDB: http://caniuse.com/#feat=indexeddb http://caniuse.com/#feat=indexeddb https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_0.html https://developer.apple.com/library/content/releasenotes/Gen... https://github.com/localForage/localForage/issues/604#issuecomment-247335607 https://github.com/localForage/localForage/issues/604#issuec... https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26 https://gist.github.com/nolanlawson/08eb857c6b17a30c1b26

dumbmatter 10y ago
Despite what some claim, Safari 10's IndexedDB is still quite broken, except possibly for some trivial cases (like if you only use one object store, or you don't use indexes): https://www.reddit.com/r/javascript/comments/545ylm/psa_indexeddb_on_safari_10_is_still_shitty/ https://www.reddit.com/r/javascript/comments/545ylm/psa_inde...
- jakub_g 10y ago
  Good to know, thanks for sharing!

tuckerjt07 10y ago

I'm currently working on a Angular2 cache management, similar to Redis, wrapper for IDB and these features will help quite a bit with a few of the lower performance operations in my API.

ralusek 10y ago

If any of you are serious about using IndexedDB, please consider: https://github.com/google/lovefield https://github.com/google/lovefield Explanation here: https://www.youtube.com/watch?v=S1AUIq8GA1k https://www.youtube.com/watch?v=S1AUIq8GA1k