Skip to content
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

Wrap OrderUpdater#update in a transaction #1569

Merged
merged 1 commit into from
Nov 28, 2016

Conversation

jhawthorn
Copy link
Contributor

As of #1479 we are doing more work inside of OrderUpdater. We're doing additions and deletions of tax adjustments, which also causes more touching of records.

This is all made faster by wrapping the entire update in a transaction. All the writes can be queued together by the DB, and as of rails 5, dependent touching is grouped together to the end of the transaction.

Difference in queries run:
https://gist.github.com/jhawthorn/5f0b9de70a782bd3e1fd2ecec667e28c

As of solidusio#1479 we are doing more work inside of OrderUpdater. We're
doing additions and deletions of tax adjustments, which also causes more
touching of records.

This is all made faster by wrapping the entire update in a transaction.
All the writes can be queued together by the DB, and as of rails 5,
dependent touching is grouped together to the end of the transaction.
@jhawthorn jhawthorn added this to the 2.1.0 milestone Oct 31, 2016
Copy link
Member

@tvdeyen tvdeyen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice. Love this kind of enhancements 🎂

@jordan-brough
Copy link
Contributor

Nice! The optimizations look great!

I'm trying to think through the consequences of having one big transaction for this. E.g. the db records from third party tax extensions, which will talk to remote services, may all be rolled back, losing track of things communicated to those services. Any thoughts or suggestions on how we handle that and how we message that to people writing these extensions?

@cbrunsdon
Copy link
Contributor

@jordan-brough yea, its a bit tough since if we dont rollback, its quite likely orders are in the "wrong" state for other reasons.

Maybe we should consider some kind of datastore which would be responsible for handling certain types of records in case of _rollback?

@cbrunsdon
Copy link
Contributor

For the record I am 👍 on this, but do echo Jordan's concerns

@jhawthorn
Copy link
Contributor Author

I'm personally pretty comfortable with any work being rolled back here in the case of an exception.

The OrderUpdater really shouldn't be raising exceptions. When it does, the most likely culprit would be issues communicating with a 3rd party tax extension, in which case it wouldn't make sense to store any data. In other cases something must have been invalid, and any stored data would likely be garbage.

@jhawthorn jhawthorn merged commit 2f5a77a into solidusio:master Nov 28, 2016
@jhawthorn jhawthorn deleted the order_update_transaction branch November 28, 2016 23:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants