New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transaction block not immediately called in Dexie 1.4.1 #268

Closed
dasboe opened this Issue Jun 8, 2016 · 3 comments

Comments

Projects
None yet
2 participants
@dasboe

dasboe commented Jun 8, 2016

Dexie 1.4.1 is breaking my current code because it handles transaction calls differently than 1.3.6.

db.transaction("rw", db.foo, function() {
  console.info("1");
}).then(function() {
  console.info("2");
});
console.info("3");

Dexie 1.3.6 output:
1
3
2

Dexie 1.4.1 output:
3
1
2

Is this changed behavior intended, I can not find anything in the documentation about it?

@dfahlander

This comment has been minimized.

Show comment
Hide comment
@dfahlander

dfahlander Jun 8, 2016

Owner

In 1.3.6 it could vary whether you would get 3,1,2 or 1,3,2 depending on whether database was finished opening, a parent transaction was locked, or not. But in most normal cases, it would be 1.3.2. Now it will always be 3,1,2. The expected order was never documented and the new order is not documented either, even though it should be.

I'm sorry this breaks your code. Is it possible to work around?

There is a reason for this change and it has to do with preventing transaction from aborting prematurely. In 1.3.6 and earlier, I had to do lots of unpleasant workarounds to keep the transaction alive. I couldn't chain promises normally which resulted in hard-to-understand code. In version 1.4+, transaction blocks always begin with Promise.resolve().then(..), which results in the 3,1,2 sequence. By doing that, I can kick-in a virtual micro-tick engine that makes sure to never let the transaction slip away between then().. calls.

Hope this explains it. Also hope you can find a way to work around the issues you get from this change.

Owner

dfahlander commented Jun 8, 2016

In 1.3.6 it could vary whether you would get 3,1,2 or 1,3,2 depending on whether database was finished opening, a parent transaction was locked, or not. But in most normal cases, it would be 1.3.2. Now it will always be 3,1,2. The expected order was never documented and the new order is not documented either, even though it should be.

I'm sorry this breaks your code. Is it possible to work around?

There is a reason for this change and it has to do with preventing transaction from aborting prematurely. In 1.3.6 and earlier, I had to do lots of unpleasant workarounds to keep the transaction alive. I couldn't chain promises normally which resulted in hard-to-understand code. In version 1.4+, transaction blocks always begin with Promise.resolve().then(..), which results in the 3,1,2 sequence. By doing that, I can kick-in a virtual micro-tick engine that makes sure to never let the transaction slip away between then().. calls.

Hope this explains it. Also hope you can find a way to work around the issues you get from this change.

@dfahlander

This comment has been minimized.

Show comment
Hide comment
@dfahlander

dfahlander Jun 8, 2016

Owner

Docs updated.
Release notes updated.

Owner

dfahlander commented Jun 8, 2016

Docs updated.
Release notes updated.

@dasboe

This comment has been minimized.

Show comment
Hide comment
@dasboe

dasboe Jun 8, 2016

Thank you for the quick reply and detailed explanation. I'm sure I will find a way to work around my problem. Keep up the great work!

dasboe commented Jun 8, 2016

Thank you for the quick reply and detailed explanation. I'm sure I will find a way to work around my problem. Keep up the great work!

@dasboe dasboe closed this Jun 8, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment