This (should) considerably improve traces like
https://app.datadoghq.com/apm/trace/917632173599137280?spanID=3163385094622710144&env=production&sort=time&colorBy=service&spanViewType=metadata&graphType=flamegraph&shouldShowLegend=true
by fixing the following 3 N+1s
```
user: root
GET /admin/customers.json?enterprise_id=4
USE eager loading detected
Customer => [:enterprise]
Add to your query: .includes([:enterprise])
Call stack
/usr/src/app/app/serializers/api/admin/customer_with_calculated_balance_serializer.rb:24:in `balance_value'
/usr/src/app/app/serializers/api/admin/customer_with_calculated_balance_serializer.rb:9:in `balance'
/usr/src/app/app/controllers/admin/customers_controller.rb:20:in `block (2 levels) in index'
/usr/src/app/app/controllers/admin/customers_controller.rb:17:in `index'
user: root
GET /admin/customers.json?enterprise_id=4
USE eager loading detected
Spree::Address => [:state]
Add to your query: .includes([:state])
Call stack
/usr/src/app/app/serializers/api/address_serializer.rb:14:in `state_name'
/usr/src/app/app/controllers/admin/customers_controller.rb:20:in `block (2 levels) in index'
/usr/src/app/app/controllers/admin/customers_controller.rb:17:in `index'
user: root
GET /admin/customers.json?enterprise_id=4
USE eager loading detected
Spree::Address => [:country]
Add to your query: .includes([:country])
Call stack
/usr/src/app/app/serializers/api/address_serializer.rb:10:in `country_name'
/usr/src/app/app/controllers/admin/customers_controller.rb:20:in `block (2 levels) in index'
/usr/src/app/app/controllers/admin/customers_controller.rb:17:in `index'
```
This popped up after improving the balances calculation. Now, that it's
fast, it's clear that are more performance problems on that endpoint.
We'll see if there are any left after this.
Where the presence of an object is being validated and that object comes from an *association*, we should use `validates :object, presence: true` instead of `validates :object_id, presence: true`.
This does not apply in the same way to validations on uniqueness of certain attributes, such as `validates :object_id, uniqueness...`
Enumerable#uniq is fine (eg calling #uniq on an Array object), but now using #uniq on an ActiveRecord::Relation is deprecated in favour of #distinct (which modifies the query itself, as opposed to iterating over the results of the query).
This fixes the error UK's is experiencing:
```
PG::AmbiguousColumn: ERROR: column reference "state" is ambiguous LINE
1: SELECT DISTINCT spree_orders.*, CASE WHEN state IN ('cancele...
^ : SELECT DISTINCT spree_orders.*, CASE WHEN state IN ('canceled',
'returned') THEN payment_total WHEN state IS NOT NULL THEN payment_total
- total ELSE 0 END AS balance_value, spree_orders.* FROM "spree_orders"
INNER JOIN "spree_shipments"
```
See
https://app.bugsnag.com/yaycode/openfoodnetwork-uk/errors/6058c45989d37300079e8312?event_id=6058ccd30075af73bcb20000&i=sk&m=nw.
Fixes:
384) Spree::OrderMailer basic behaviour doesn't aggressively escape double quotes in confirmation body
Failure/Error: adjustments = adjustments.to_a + order.shipment_adjustments.to_a
ActionView::Template::Error:
Cannot have a has_many :through association 'Spree::Order#shipment_adjustments' which goes through 'Spree::Order#shipments' before the through association is defined.
# ./app/helpers/checkout_helper.rb:10:in `checkout_adjustments_for'
# ./app/views/spree/order_mailer/_order_summary.html.haml:43:in `_app_views_spree_order_mailer__order_summary_html_haml__2911251238692323485_70331958934800'
# ./app/views/spree/order_mailer/confirm_email_for_customer.html.haml:23:in `_app_views_spree_order_mailer_confirm_email_for_customer_html_haml__3734564010704881256_70331959518520'
# ./app/mailers/spree/order_mailer.rb:35:in `block in confirm_email_for_customer'
# ./app/mailers/spree/order_mailer.rb:33:in `confirm_email_for_customer'
# ./spec/mailers/order_mailer_spec.rb:20:in `block (3 levels) in <top (required)>'
# ------------------
# --- Caused by: ---
# ActiveRecord::HasManyThroughOrderError:
# Cannot have a has_many :through association 'Spree::Order#shipment_adjustments' which goes through 'Spree::Order#shipments' before the through association is defined.
# ./app/helpers/checkout_helper.rb:10:in `checkout_adjustments_for'
Fixes:
259) Spree::ShippingMethod#shipments can gather all the related shipments
Failure/Error: expect(shipping_method.shipments).to include(shipment)
ActiveRecord::HasManyThroughOrderError:
Cannot have a has_many :through association 'Spree::ShippingMethod#shipments' which goes through 'Spree::ShippingMethod#shipping_rates' before the through association is defined.
# ./spec/models/spree/shipping_method_spec.rb:190:in `block (3 levels) in <module:Spree>'
Fixes:
292) OrderManagement::Subscriptions::ProxyOrderSyncer#sync! when the subscription is not persisted and the schedule includes upcoming oc that closes after ends_at does not create a new proxy order for that oc
Failure/Error: order_cycle.schedules << schedule
ActiveRecord::HasManyThroughOrderError:
Cannot have a has_many :through association 'OrderCycle#schedules' which goes through 'OrderCycle#order_cycle_schedules' before the through association is defined.
# ./spec/factories.rb:29:in `block (4 levels) in <top (required)>'
# ./spec/factories.rb:28:in `each'
# ./spec/factories.rb:28:in `block (3 levels) in <top (required)>'
# ./engines/order_management/spec/services/order_management/subscriptions/proxy_order_syncer_spec.rb:59:in `block (4 levels) in <module:Subscriptions>'
# ./engines/order_management/spec/services/order_management/subscriptions/proxy_order_syncer_spec.rb:65:in `block (4 levels) in <module:Subscriptions>'
# ./engines/order_management/spec/services/order_management/subscriptions/proxy_order_syncer_spec.rb:133:in `block (6 levels) in <module:Subscriptions>'
# ./engines/order_management/spec/services/order_management/subscriptions/proxy_order_syncer_spec.rb:133:in `block (5 levels) in <module:Subscriptions>'
Failure/Error: enterprise.andand.touch
ActiveRecord::ActiveRecordError:
cannot touch on a new or destroyed record object. Consider using persisted?, new_record?, or destroyed? before touching
# ./app/models/spree/address.rb:155:in `touch_enterprise'
# ./spec/factories/product_factory.rb:12:in `block (3 levels) in <top (required)>'
# ./spec/factories/variant_factory.rb:26:in `block (4 levels) in <top (required)>'
# ./spec/models/spree/variant_spec.rb:9:in `block (2 levels) in <module:Spree>'
This was being triggered by a callback in Spree::Adjustments before, but now that the adjustable is not the order, it does not get triggered by fees being added to line items...
