-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
In-memory order updater #5872
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
base: main
Are you sure you want to change the base?
In-memory order updater #5872
Conversation
27f19a8
to
340032c
Compare
d22210b
to
d244646
Compare
Just making a note that we are waiting on Alistair to rebase #6026 against this. @AlistairNorman could you just make sure that gets done at some point before the 20th? That way we can have it for our next session. |
a3bb1fc
to
06e3a2a
Compare
9fd5c8d
to
27e4988
Compare
4a0f623
to
90f5420
Compare
While working on the in-memory updater in solidusio#5872, we found the need to change how item totals were being calculated, so that we could mark adjustments for destruction without actually destroying them, while still keeping tax adjustments intact. This change is completely backwards-compatible with the current OrderUpdater, so to reduce the scope of our PR, we wanted to make this change separately. Since the OrderUpdater is already very large, this helps reduce its responsibilities and makes it easier to test this behaviour. We don't see it as necessary to make this a configurable class, but this change leaves that option open in the future. Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: Chris Todorov <chris@super.gd> Co-authored-by: Harmony Bouvier <harmony@super.gd> Co-authored-by: Sofia Besenski <sofia@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd>
While working on the in-memory updater in solidusio#5872, we found the need to change how item totals were being calculated, so that we could mark adjustments for destruction without actually destroying them, while still keeping tax adjustments intact. This change is completely backwards-compatible with the current OrderUpdater, so to reduce the scope of our PR, we wanted to make this change separately. Since the OrderUpdater is already very large, this helps reduce its responsibilities and makes it easier to test this behaviour. We don't see it as necessary to make this a configurable class, but this change leaves that option open in the future. Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: Chris Todorov <chris@super.gd> Co-authored-by: Harmony Bouvier <harmony@super.gd> Co-authored-by: Sofia Besenski <sofia@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd>
While working on the in-memory updater in solidusio#5872, we found the need to change how item totals were being calculated, so that we could mark adjustments for destruction without actually destroying them, while still keeping tax adjustments intact. This change is completely backwards-compatible with the current OrderUpdater, so to reduce the scope of our PR, we wanted to make this change separately. Since the OrderUpdater is already very large, this helps reduce its responsibilities and makes it easier to test this behaviour. We don't see it as necessary to make this a configurable class, but this change leaves that option open in the future. Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: Chris Todorov <chris@super.gd> Co-authored-by: Harmony Bouvier <harmony@super.gd> Co-authored-by: Sofia Besenski <sofia@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd>
While working on the in-memory updater in solidusio#5872, we found the need to change how item totals were being calculated, so that we could mark adjustments for destruction without actually destroying them, while still keeping tax adjustments intact. This change is completely backwards-compatible with the current OrderUpdater, so to reduce the scope of our PR, we wanted to make this change separately. Since the OrderUpdater is already very large, this helps reduce its responsibilities and makes it easier to test this behaviour. We don't see it as necessary to make this a configurable class, but this change leaves that option open in the future. Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: Chris Todorov <chris@super.gd> Co-authored-by: Harmony Bouvier <harmony@super.gd> Co-authored-by: Sofia Besenski <sofia@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd>
9ecbd13
to
92fc679
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5872 +/- ##
==========================================
+ Coverage 89.35% 89.41% +0.05%
==========================================
Files 961 964 +3
Lines 20195 20351 +156
==========================================
+ Hits 18046 18197 +151
- Misses 2149 2154 +5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
92fc679
to
e7faef3
Compare
f3d92a4
to
a5ed6c6
Compare
d0322b2
to
07add2a
Compare
d22dbf5
to
770e527
Compare
770e527
to
c8e434e
Compare
7bf4adb
to
2d497bd
Compare
67186f3
to
defde7e
Compare
5423a0e
to
62209cf
Compare
2b60e3b
to
083fafe
Compare
These methods don't persist so it's more accurate to say that they recalculate the total instead of saying that they update it. Co-Authored-By: Adam Mueller <adam@super.gd> Co-Authored-By: benjamin wil <benjamin@super.gd> Co-Authored-By: Andrew Stewart <andrew@super.gd> Co-Authored-By: Harmony Bouvier <harmony@super.gd> Co-Authored-By: Jared Norman <jared@super.gd> Co-Authored-By: Kendra Riga <kendar@super.gd> Co-Authored-By: Sofia Besenski <sofia@super.gd> Co-Authored-By: Chris Todorov <chris@super.gd> Co-Authored-By: Tom Van Manen <tom@super.gd> Co-Authored-By: Noah Silvera <noah@super.gd>
This puts all the update and recalculate methods together. Co-Authored-By: Adam Mueller <adam@super.gd> Co-Authored-By: benjamin wil <benjamin@super.gd> Co-Authored-By: Andrew Stewart <andrew@super.gd> Co-Authored-By: Harmony Bouvier <harmony@super.gd> Co-Authored-By: Jared Norman <jared@super.gd> Co-Authored-By: Kendra Riga <kendar@super.gd> Co-Authored-By: Sofia Besenski <sofia@super.gd> Co-Authored-By: Chris Todorov <chris@super.gd> Co-Authored-By: Tom Van Manen <tom@super.gd> Co-Authored-By: Noah Silvera <noah@super.gd>
We want all the methods that might persist data to be called update_ instead of recalculate to be clear that they hit the database. Co-Authored-By: Adam Mueller <adam@super.gd> Co-Authored-By: benjamin wil <benjamin@super.gd> Co-Authored-By: Andrew Stewart <andrew@super.gd> Co-Authored-By: Harmony Bouvier <harmony@super.gd> Co-Authored-By: Jared Norman <jared@super.gd> Co-Authored-By: Kendra Riga <kendar@super.gd> Co-Authored-By: Sofia Besenski <sofia@super.gd> Co-Authored-By: Chris Todorov <chris@super.gd> Co-Authored-By: Tom Van Manen <tom@super.gd> Co-Authored-By: Noah Silvera <noah@super.gd>
This is calling the recalculate method not update_adjustments. Co-Authored-By: Adam Mueller <adam@super.gd> Co-Authored-By: benjamin wil <benjamin@super.gd> Co-Authored-By: Andrew Stewart <andrew@super.gd> Co-Authored-By: Harmony Bouvier <harmony@super.gd> Co-Authored-By: Jared Norman <jared@super.gd> Co-Authored-By: Kendra Riga <kendar@super.gd> Co-Authored-By: Sofia Besenski <sofia@super.gd> Co-Authored-By: Chris Todorov <chris@super.gd> Co-Authored-By: Tom Van Manen <tom@super.gd> Co-Authored-By: Noah Silvera <noah@super.gd>
Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Andrew Stewart <andrew@super.gd> Co-authored-by: Jared Norman <jared@super.gd> Co-authored-by: Noah Silvera <noah@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd>
Includes a small refactor to the internal recalculate method to simplify the code while maintaining the existing logic around only persisting when the values have changed. We'll use this persist flag to eventually only save changes to the DB when requested. Allowing us to use this adjuster to update the order in-memory. Co-authored-by: An Stewart <andrew@super.gd> Co-authored-by: Harmony Evangelina <harmony@super.gd> Co-authored-by: Kendra Riga <kendra@super.gd> Co-authored-by: Nick Van Doorn <nick@super.gd> Co-authored-by: Sofia Besenski <sofia@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd>
Similar to the previous change. We're now passing the persist flag down to all promotion order adjusters. This does not implement the logic within the individual adjuster classes to skip persistance when required, only ensures the flag is pass down from our in-memory order updater. Co-Authored-By: Adam Mueller <adam@super.gd> Co-Authored-By: Andrew Stewart <andrew@super.gd> Co-Authored-By: Harmony Evangelina <harmony@super.gd> Co-Authored-By: Jared Norman <jared@super.gd> Co-Authored-By: Kendra Riga <kendra@super.gd> Co-Authored-By: Senem Soy <senem@super.gd> Co-Authored-By: benjamin wil <benjamin@super.gd>
Previously this would update the eligible column. We now only assign the value and then save if persist is true. Co-Authored-By: Adam Mueller <adam@super.gd> Co-Authored-By: Andrew Stewart <andrew@super.gd> Co-Authored-By: Harmony Evangelina <harmony@super.gd> Co-Authored-By: Jared Norman <jared@super.gd> Co-Authored-By: Kendra Riga <kendra@super.gd> Co-Authored-By: benjamin wil <benjamin@super.gd> Co-Authored-By: Chris Todorov <chris@super.gd> Co-Authored-By: Nick Van Doorn <nick@super.gd> Co-Authored-By: Sofia Besenski <sofia@super.gd>
We were missing the whole path of doing order level adjustments, e.g. The CreateDiscountedItem benefit.
This is in service of the in-memory order updater. Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: Andrew Stewart <andrew@super.gd> Co-authored-by: benjamin wil<benjamin@super.gd> Co-authored-by: Chris Todorov <chris@super.gd> Co-authored-by: Harmony Bouvier <harmony@super.gd> Co-authored-by: Jared Norman <jared@super.gd> Co-authored-by: Nick Van Doorn <nick@super.gd> Co-authored-by: Noah Silvera <noah@super.gd> Co-authored-by: Senem Soy <senem@super.gd> Co-authored-by: Sofia Besenski <sofia@super.gd>
Integration level test using the InMemoryOrderUpdater to ensure we are not persisting changes during the promotion recalculations. Co-authored-by: Chris Todorov <chris@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd> Co-authored-by: An Stewart <andrew@super.gd> Co-authored-by: Jared Norman <jared@super.gd>
This change introduces some high-level integration tests and a patch similar to the one for the regular order updater, which provides a compatibility layer for the legacy promotion system, specifically around the eligible flag on adjustments. We want to protect against manipulative database queries in the legacy promotion system. We also want to ensure that objects in memory have their attributes changed correctly but not persisted. Co-authored-by: Jared Norman <jared@super.gd> Co-authored-by: Kendra Riga <kendra@super.gd> Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: Senem Soy <senem@super.gd> Co-authored-by: Sofia Besenski <sofia@super.gd> Co-authored-by: Noah Silvera <noah@super.gd>
Instead of destroying. See code comments and spec changes. This is similar to how we handled this in the legacy promotion system. Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: An Stewart <andrew@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd> Co-authored-by: Harmony Evangelina <harmony@super.gd> Co-authored-by: Jared Norman <jared@super.gd> Co-authored-by: Nick Van Doorn <nick@super.gd> Co-authored-by: Senem Soy <senem@super.gd> Co-authored-by: Sofia Besenski <sofia@super.gd>
When computing item totals after a line item benefit is removed, we need to ensure we aren't using the marked for destruction items. We also needed to make a change to the legacy promotion order updater patch because it is incorrectly being used in our tests even when using the new promotion system. It also did not have logic to ensure adjustments that were marked for destruction were ignored in the adjustment totals calculation. Co-authored-by: Jared Norman <jared@super.gd> Co-authored-by: Noah Silvera <noah@super.gd>
In an associated change we made the `CreateDiscountedItem` benefit create in-memory line items. That causes an issue during the recalculation of the item totals. Co-authored-by: benjamin wil <benjamin@super.gd> Co-authored-by: Kendra Riga <kendra@super.gd> Co-authored-by: Noah Silvera <noah@super.gd> Co-authored-by: Jared Norman <jared@super.gd>
This will be used by the in-memory order updater to log manipulative queries when the persist flag is set to false. This will inform application developers whether their application is complying with the in-memory order updater's "no writes" philosophy. Previously the `db-query-matchers` gem we use to check for manipulative queries was only used in tests. However, we now use it in application code so the dependency must be moved to the gemspec. Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: Sofia Besenski <sofia@super.gd> Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Chris Todorov <chris@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd>
Enabling manipulative query logging will show the number of manipulative queries on each call to Spree::InMemoryOrderUpdater#recalculate. Co-authored-by: Chris Todorov <chris@super.gd> Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: Senem Soy <senem@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd>
This method will be used in the in memory order updater. We only want to persist to the database once we perform the action, not when we are computing the amount.
We want to make sure we don't persist anything when computing amounts becuase that will cause issues with the in-memory order updater.
Co-authored-by: benjamin wil <benjamin@super.gd> Co-authored-by: Chris Todorov <chris@super.gd>
Instead of calling update_columns, we should just use assign_attributes everywhere and rely on our order persistance bubbling down to the line item when appropriate. This avoids issues with the in-memory order updater when attempting to update values on newly created promotional items that won't get persisted until later in the recalculation flow. Co-authored-by: Jared Norman <jared@super.gd> Co-authored-by: Noah Silvera <noah@super.gd>
Sets up some shared examples so that we can run the full promotion integration suite against both the existing order updater and the in-memory order updater. Co-authored-by: Jared Norman <jared@super.gd> Co-authored-by: Noah Silvera <noah@super.gd>
We no longer want to have individual methods use a persist: flag, instead we can save at the end if needed. Co-authored-by: Chris Todorov <chris@super.gd> Co-authored-by: Senem Soy <senem@super.gd> Co-authored-by: benjamin wil <benjamin@super.gd>
We no longer want to have individual methods use a persist: flag, instead we can save at the end if needed.
We don't want our in-memory order updater to have to persist shipment state. Because we no longer rely on `Shipment#update_state` which uses `update_column`, we are now logging any additional `Shipment#state` changes when the order is saved. The changes to the specs reflect this change in behaviour. Co-authored-by: Jared Norman <jared@super.gd> Co-authored-by: Noah Silvera <noah@super.gd> Co-authored-by: Alistair Norman <alistair@super.gd>
Due to upstream changes after a rebase, these tests started failing because the `order` being set up (`Spree::Order.create`) did not have proper shipments or inventory units created for it. The new tests use factories to more realistically set up orders, shipments, and inventory units in various states to simulate order updater functionality. Co-authored-by: Alistair Norman <alistair@super.gd> Co-authored-by: Kendra Riga <kendra@super.gd> Co-authored-by: Chris Todorov <chris@super.gd>
On the classic order updater, we were persisting updates to shipment and payment states in the respective recalculate methods. We are no longer persisting changes in those methods; now we only save changes in `#persist_totals`, so this is where we should be logging. Co-authored-by: Senem Soy <senem@super.gd> Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Kendra Riga <kendra@super.gd>
This removes the deprecation warnings from our test suite. Co-authored-by: Adam Mueller <adam@super.gd> Co-authored-by: Kendra Riga <kendra@super.gd> Co-authored-by: Senem Soy <senem@super.gd>
We're proposing a new default for this configuration value, so this change updates the test in the new promotion system to not be dependent on the current default value. This test will fail if the default configuration changes. Co-authored-by: Benjamin Willems <benjamin@super.gd> Co-authored-by: Kendra Riga <kendra@super.gd> Co-authored-by: Adam Mueller <adam@super.gd>
924533f
to
fd321b6
Compare
Summary
This pull request proposes a replacement to the default
Spree::OrderUpdater
that has new and improved functionality:There may be some beneficial side-effects that come out of this new order updater implementation:
We don't expect this to be the default order updater implementation in the next minor version of Solidus, but we would like to propose it as the default for the next major version of Solidus.
Note: The commits on this pull request have a long list of co-authors, as the Super Good team is approaching this as a collaborative mob programming exercise.
Milestones
For this order updater, we intend to achieve the following during updates:
We appreciate that there is a lot of complexity to achieving these goals (dealing with active promotions, for example).
Notes
Spree::OrderUpdater
makes on a typical recalculate.Todo
recalculate_item_total
when line item totals changeInMemoryOrderUpdater
to not marked for destructionOrderUpdater
to not marked for destructionupdate_taxes
Write theInMemoryOrderAdjuster
(also, should we rename this toInMemoryOrderPromotionAdjuster
)LineItem#set_required_attributes
inafter_initialize
instead ofbefore_validation
. We think this may be a breaking change that requiresfurther investigation. (We investigated and don't believe it is a breaking change.)
ensure the above
promotions.order_adjuster_class
Spree::LineItem#set_required_attributes
compute_amount
. We know the create quantity adjustments does. This action persists when compute_amount is called.persist: false
Checklist
Check out our PR guidelines for more details.
The following are mandatory for all PRs:
The following are not always needed: