Use in-memory objects for adjustments in ItemAdjustments#1401
Merged
jhawthorn merged 17 commits intosolidusio:masterfrom Aug 31, 2016
Merged
Use in-memory objects for adjustments in ItemAdjustments#1401jhawthorn merged 17 commits intosolidusio:masterfrom
jhawthorn merged 17 commits intosolidusio:masterfrom
Conversation
jordan-brough
force-pushed
the
in-memory-objects-in-item-adjustments
branch
from
0b8c268 to
d470868
Compare
So that in-memory associations stay up to date for calculations in
OrderUpdater and elsewhere.
E.g. if you do this:
Spree::Adjustment.create!(adjustable: line_item, ...)
Then `line_item.adjustments` does not get updated if it's already
loaded.
Also this:
source.adjustments.create!(adjustable: line_item, ...)
likewise doesn't update `line_item.adjustments`.
The code in this commit is not the most lovely code, but I couldn't
think of a better option for the time being, given that we expose all
of ActiveRecord as an interface and it's likely that extensions and/or
stores themselves have code like the above in, for example, their
promotion actions.
Using all_adjustments bypasses the individual `adjustments` associations (order.adjustments, line_item.adjustments & shipment.adjustments) which makes them outdated for further use.
Using order.inventory_units bypasses `line_item.adjustments` which makes them outdated for further use.
This ensures that the same object is used as the one inside `item.adjustments` so that it's kept up to date correctly
This avoids extra queries and should improve performance. It also should make refactoring easier without adding extra queries, including some upcoming tax-refactoring I'm working on.
So that the in-memory objects are updated.
This switches to update the adjustable `adjustments` instead of the promotion action adjustments. The former is most likely more important.
This keeps `item.adjustments` up to date.
This switches to update the adjustable `adjustments` instead of the tax rate adjustments. The former is most likely more important.
This keeps `line_item.adjustments` up to date.
This makes it the same as all the other `adjustments` relationships which makes the repair code in Adjustment simpler, and it makes it easier to query for duplicates. Also, use `line_item.adjustments.create` instead of `unit_cancel.adjustments.create`. The latter bypasses `line_item.adjustments` which makes them outdated for further use.
`create(:adjustment)` seems like a reasonble thing to do, but it doesn't update, e.g., `line_item.adjustments` and triggers the warning we have in place in Adjustment.
Nest :tax_adjustment factory under :adjustment factory Avoids duplicated `after_build` code.
This shouldn't happen in Solidus core anymore.
jordan-brough
force-pushed
the
in-memory-objects-in-item-adjustments
branch
from
d470868 to
1e60956
Compare
| order.all_adjustments.tax.destroy_all | ||
| [order, *order.line_items, *order.shipments].each do |item| | ||
| item.adjustments.destroy(item.adjustments.select(&:tax?)) | ||
| end |
Contributor
There was a problem hiding this comment.
Instead of this we should probably fix this line https://github.com/solidusio/solidus/blob/master/core/app/models/spree/tax/item_adjuster.rb#L31
and then remove the skip_destroy_adjustments option
orders here should never have tax adjustments (they've been only on items since spree 2.2), so I don't think we need to consider that
This `destroy_all` was on a scope and thus could cause data to be out of sync. And, as mentioned by jhawthorn in the PR review we can move tax adjustment destroys to ItemAdjuster because: > orders here should never have tax adjustments (they've been only on > items since spree 2.2)
Contributor
|
Thank you for those 👍 Would they actually make it into the 1.x branch, or only onto the Rails5 one? |
Contributor
|
👍 |
|
|
||
| belongs_to :inventory_unit | ||
| has_one :adjustment, as: :source, dependent: :destroy | ||
| has_many :adjustments, as: :source, dependent: :destroy |
Contributor
There was a problem hiding this comment.
Perhaps this change would merit an entry in the CHANGELOG?
Contributor
Author
There was a problem hiding this comment.
@bbuchalter good point. I updated to @jhawthorn's solution though, so I've reverted back to has_one.
Per PR feedback. Avoid changing the `has_many`/`has_one` relationship while still keeping in-memory objects up to date.
Contributor
Author
|
FYI I've added a Changelog entry for this and the related PRs. |
Contributor
|
Looks great to me, really fantastic work, thanks 👍 and anyone that contributed eyes. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See individual commits.
This avoids extra queries and should improve performance.
It also should make refactoring easier without adding extra queries,
including some upcoming tax-refactoring I'm working on.
The two primary commits are these:
adjustmentsrelationships" - a workaround for backward-compatibilityI'm not super happy with the above workaround, but I couldn't think of a better option. Also, it makes me nervous that we need a workaround like that in the first place -- it seems like this could be fragile. See, for example, the "Don't use all_adjustments in OrderAdjuster" commit. Using
all_adjustmentsin the "wrong" way can result in outdated in-memory objects and thus incorrect calculations.Relates to #1252 and previous work done in #1356, #1389, and #1400.