Are there any plans to make IndexedDB and promises play nice?

2015-04-16 Thread Jeremy Scheff 
Currently, wrapping IndexedDB in promises is a perilous task. Pun intended,
since the sticking point seems to be the distinction between microtasks and
macrotasks. See http://stackoverflow.com/q/28388129/786644 for an example.
Basically, it's not clear whether resolving a promise should auto-commit a
transaction or not. Behavior varies across browsers and promise libraries,
and I don't even know what the correct behavior actually is.

Although having the IndexedDB API completely redone in promises would be
nice, I understand that may be too big of a change to be feasible. That's
fine. All I really would like is for there to be some way to wrap the
event-based API in promises without things breaking.

So what's the current status of IndexedDB and promises? Is there any hope
that they will work well together in the near future?

--
Jeremy Scheff

Re: Are there any plans to make IndexedDB and promises play nice?

2015-04-16 Thread Anne van Kesteren 
On Thu, Apr 16, 2015 at 12:04 AM, Jeremy Scheff jdsch...@gmail.com wrote:
 Currently, wrapping IndexedDB in promises is a perilous task. Pun intended,
 since the sticking point seems to be the distinction between microtasks and
 macrotasks. See http://stackoverflow.com/q/28388129/786644 for an example.
 Basically, it's not clear whether resolving a promise should auto-commit a
 transaction or not. Behavior varies across browsers and promise libraries,
 and I don't even know what the correct behavior actually is.

Part of the problem is that the correct behavior is not defined in
detail. ECMAScript defines a Job Queue. HTML defines an event loop.
The idea is that as part of HTML's event loop, promises integrate as
microtasks. HTML's event loop would basically deplete the Job Queue
each task. However, this is not defined because the exact integration
with the model ECMAScript landed on is rather cumbersome. It would be
much easier if ECMAScript queued Jobs to the host environment along
with some metadata.


 Although having the IndexedDB API completely redone in promises would be
 nice, I understand that may be too big of a change to be feasible.

I believe that is also impossible due to the mismatch between
transaction semantics and promise semantics.


-- 
https://annevankesteren.nl/

Re: Are there any plans to make IndexedDB and promises play nice?

2015-04-16 Thread Joshua Bell 
On Thu, Apr 16, 2015 at 6:04 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Thu, Apr 16, 2015 at 12:04 AM, Jeremy Scheff jdsch...@gmail.com
 wrote:
  Currently, wrapping IndexedDB in promises is a perilous task. Pun
 intended,
  since the sticking point seems to be the distinction between microtasks
 and
  macrotasks. See http://stackoverflow.com/q/28388129/786644 for an
 example.
  Basically, it's not clear whether resolving a promise should auto-commit
 a
  transaction or not. Behavior varies across browsers and promise
 libraries,
  and I don't even know what the correct behavior actually is.

 Part of the problem is that the correct behavior is not defined in
 detail. ECMAScript defines a Job Queue. HTML defines an event loop.
 The idea is that as part of HTML's event loop, promises integrate as
 microtasks. HTML's event loop would basically deplete the Job Queue
 each task. However, this is not defined because the exact integration
 with the model ECMAScript landed on is rather cumbersome. It would be
 much easier if ECMAScript queued Jobs to the host environment along
 with some metadata.


Yep. Tracking it in Chrome at crbug.com/457409 (which has links to past
discussions, too) but even though my preference is that the autocommit
behavior should occur at the end of any task-or-microtask that doesn't
match web reality or what I can tease out of the specs even given what Anne
lists above. So... we're in a holding pattern.



  Although having the IndexedDB API completely redone in promises would be
  nice, I understand that may be too big of a change to be feasible.

 I believe that is also impossible due to the mismatch between
 transaction semantics and promise semantics.


slightlyoff@ and I have dome some brainstorming in this area. TL;DR: if we
borrow the waitUntil(Promiseany) notion from Service Worker's
ExtendableEvent to allow you to prop open a transaction then you can
incorporate a promise flow with IDB. This violates the intent of IDB's
quick auto-close transaction design and allows you to hold open a
transaction forever, and it also doesn't address wanting to compose
transactions more sensibly across APIs (e.g. coordinated abort/commit
signals, etc) so it's not yet ready for serious consideration.

I'm not convinced it's impossible per se, but I'm also not convinced that
the resulting API is actually particularly usable.

...

The one thing I'd push for doing short term is adding .promise(), .then()
and .catch() to IDBTransaction to make chaining promises *after*
transactions easier. That seems fairly low risk.

(Doing the same with IDBRequest is fraught with peril due to the issue
raised by the OP: by the time the then-callback microtask runs the
transaction will be inactive and/or autocommitting)