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

On Thu, Apr 16, 2015 at 6:04 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Apr 16, 2015 at 12:04 AM, Jeremy Scheff <jdscheff@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(Promise<any>) 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)