5 ms·

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.

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.