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

[v3.2] Fix variant price performance regressions #4657

Closed
wants to merge 10 commits into from

Conversation

mamhoff
Copy link
Contributor

@mamhoff mamhoff commented Oct 4, 2022

Summary

Backport of #4639 to the v3.2 branch.

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

  • I have written a thorough PR description.
  • I have kept my commits small and atomic.
  • I have used clear, explanatory commit messages.

The following are not always needed (cross them out if they are not):

  • I have added automated tests to cover my changes.
  • I have attached screenshots to demo visual changes.
  • I have opened a PR to update the guides.
  • I have updated the readme to account for my changes.

@gsmendoza gsmendoza added the type:bug Error, flaw or fault label Oct 18, 2022
@mamhoff mamhoff force-pushed the variant-prices-3.2 branch from 1b1b581 to 9bc9193 Compare October 19, 2022 08:52
When we soft-delete a variant, we also soft-delete the variant's prices.
In my opinion, this is not necessary, as the association between prices
and variants includes discarded prices, and harmful, as it leads to
price inconsistencies between a variant before discarding and after
undiscarding (if the variant has a newer, but discarded, price, we have
no way of knowing that that price should not be un-discarded along with
the variant).
Using the `currently_valid` scope in this instance method leads to an
"n+1" issue when getting prices for more than one variant. By sorting
these in memory rather than in the database, we can save a lot of
database round-trips.
This uses the redefined public method from the previous commit to detect
the default price. Note that through using `reverse_each.detect` rather
than `min` with a block we should be able to save some iterations.
This was the previous behavior.
We don't need to be using the weirdly named `currently_valid_prices`
method. As this is the only spot in core where we use that method, we
can now deprecate it.
@mamhoff mamhoff force-pushed the variant-prices-3.2 branch from 9bc9193 to a920d3f Compare October 19, 2022 08:57
This uses the price selector in order to find the default price rather
than having to re-implement the default price selector's logic.
Previous Solidus behavior included soft-deleted prices when looking at
the default price. The intention of this behavior was that a a variant
that is soft-deleted, and has its prices soft-deleted as a consequence,
still has a `default_price` record.

However, for a `kept` variant, we do not want to see a discarded
`default_price` - otherwise what sense does it make to even add the
delete action to the price? Especially given that deletion touches the
variant and will then move it forward in the array of sorted prices to
be considered for a given set of pricing attributes.

This commit changes the `prices` association to include discarded
prices, but then filters out discarded prices for non-discarded
variants in the price selector.
@mamhoff
Copy link
Contributor Author

mamhoff commented Oct 19, 2022

Recreated from changes merged in main branch.

@waiting-for-dev
Copy link
Contributor

Closing in favor of #4690

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug Error, flaw or fault
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants