Re: Indexed DB + Promises

IDB already aborts the transaction if errors are thrown in callbacks.
Additionally, in the promise proposal, if the promise passed to .waitUntil
rejects, the transaction aborts. Does this address your concerns?

On Wed, 30 Sep 2015, 08:26 Conrad Irwin <conrad.irwin@gmail.com> wrote:

> One of the things I like about the WebSQL API is that the transaction
> aborts if any queries fail or if any callbacks throw errors. This way the
> whole transaction can be handled as a promise easily, which provides nice
> abstraction to the calling code.
>
> It comes at the expense of each individual operation being promisified,
> each operation still takes a callback so that you know for sure when code
> is 'done' handling a result (it's hard to tell when a promise is done
> because .then can be called multiple times and at any time).
>
> I would like to see any work on IndexedDb promises go the same way:
>
> 1. Figure out how to tell if a transaction succeeded or failed.
> 2. Wrap the transaction in a promise, so that code can be structured at a
> high level with promises.
> 3. (Optional) represent each request as a promise, if that's compatible
> with goal 1.
>
> If I remember rightly it's hard to do 1 in general with the current
> non-promise based API, so any change to make the  API more promise
> based should first address that.
>
> Conrad
>
>
>
>
> On Tuesday, September 29, 2015, Jake Archibald <jaffathecake@gmail.com>
> wrote:
>
>> I agree with Jonas, I'd like to see IDBRequest and IDBTransaction be
>> thenables. This could be done by having a hidden promise, and having
>> .then/.catch proxy to the same methods on the hidden promise.
>>
>> We just have to get over the throw/reject thing.
>>
>> On Tue, 29 Sep 2015, 23:16 Jonas Sicking <jonas@sicking.cc> wrote:
>>
>>> On Tue, Sep 29, 2015 at 10:51 AM, Domenic Denicola <d@domenic.me> wrote:
>>> > This seems ... reasonable, and quite possibly the best we can do. It
>>> has a several notable rough edges:
>>> >
>>> > - The need to remember to use .promise, instead of just having
>>> functions whose return values you can await directly
>>>
>>> One way that we could solve this would be to make IDBRequest a
>>> thenable. I.e. put a .then() function directly on IDBRequest.
>>>
>>> > - The two-stage error paths (exceptions + rejections), necessitating
>>> async/await to make it palatable
>>>
>>> I'd be curious to know if, in the case of IDB, this is a problem in
>>> practice. I do agree that it's good for promise based APIs to only
>>> have one error path, but IDB is pretty conservative about when it
>>> throws.
>>>
>>> Do people actually wrap their IDB calls in try/catch today?
>>>
>>> Certainly throwing at all isn't perfect, but is it a big enough
>>> problem that it warrants using a library?
>>>
>>> > - The waitUntil/IIAFE pattern in the incrementSlowly example, instead
>>> of a more natural `const t = await openTransaction(); try { await
>>> useTransaction(t); } finally { t.close(); }` structure
>>>
>>> I'm actually quite concerned about using a t.close() pattern. It seems
>>> to make it very easy to end up with minor bugs which totally hang an
>>> application because a transaction is left open.
>>>
>>> But maybe developers prefer it strongly enough that they'll use a
>>> library which provides it.
>>>
>>> > I guess part of the question is, does this add enough value, or will
>>> authors still prefer wrapper libraries, which can afford to throw away
>>> backward compatibility in order to avoid these ergonomic problems?
>>>
>>> Yeah, I think this is a very good question. I personally have no idea.
>>>
>>> / Jonas
>>>
>>>