Why don't Promises break me out of transaction scope?

[mikemorton]

The following is generating an error about using a read-write transaction inside a read-only transaction

db.transaction('r', [this.generalInfo, this.players], () =>{
   Promise.all([this.generalInfo.toArray(), this.players.toArray()]).then((results) =>{
      this.doStuff(results);
   });
});

function doStuff(results) {  
  return new Promise((resolve, _reject) => {
    this.transaction('rw', this.allTables(), () => {
      // more code here
    });
  });
}

This generates an error:

Cannot enter a sub-transaction with READWRITE mode when parent transaction is READONLY

I've read the transaction documentation and it sounds like I can just put a ! or a ? on the READWRITE transaction in order to get what I want, but I must say this behavior was surprising because I thought that the Promises would break me out of transaction scope.

Questions:

1. Why doesn't using Promise.all break me out of the transaction scope?
2. Failing that, Why doesn't creating a new Promise in the doStuff function break me out of the transaction scope?
3. Somewhat unrelated, but is there a better way to fetch a bunch of data I need for my operation other than using Promise.all with a bunch of toArray() calls inside?

[mikemorton]

Re-reading the best practices docs I now see that using browser native Promises do not break out of scope, by design! That's cool and impressive.

Anyways, I do feel like there was somewhere else I read that made me feel that this shouldn't work. If I can dig it up I'll post here.

[dfahlander]

yes it used to be so in version 1.x. Docs have been updated in 2.0

[mikemorton]

Thanks for the reply @dfahlander - I'm curious how this works! Could you point me to the portion of the code that is responsible for keeping the transaction alive in this case?

[dfahlander]

Just to clarify two different issues:

1. First we have the issue that promises didn't play well with IDB transactions at all. That was solved a couple of years ago by the browser vendors. That issue still remains in IndexedDBShim and old browsers. Dexie has always worked around that using Dexie.Promise.
2. Then we have Dexie's transaction scopes / zones that also need to be maintained.

In Dexie version 1.x, you had to stick to using Dexie.Promise for both these reasons. In Dexie version 2, zones will also temporarily replace the global Promise with Dexie's Promise - only for the code that is executing within the zone - so that the global promise becomes both IDB compliant on old browsers and in IndexedDBShim, and continues to maintain the zones. Note that the global Promise is always restored whenever leaving a zone - so we don't affect other code than what's executed in the transaction scopes. This is what makes the global Promise possible to use in Dexie >= 2.0, and also recommended in the docs.

Then comes a third issue: native async/await - which uses the native global internally - no matter if you've replaced the global promise or not. This is also worked around in Dexie using my own invention that I call "zone echoing". I will not go into it too much here. However, zone echoing does only maintain zones across await calls and cannot fix the first issue of old browsers and IDBShim that doesn't play well with promises. However, as said before, modern browser don't have that issue anymore.

The code that handles all these three things is in src/helpers/promise.js (one of the few modules that hasn't been converted to typescript yet).

[dfahlander]

If your intent is to break out of the transaction zone, use [Dexie.ignoreTransaction()](https://dexie.org/docs/Dexie/Dexie.ignoreTransaction()).