These objects can hold critical information related to adjustments and tax categories. If they are hard-deleted we lose vital data that's needed by associated records.
This speeds up a great deal one of the most awful queries our DB servers
execute. It's not rare to see traces above 20s in Datadog 😱.
In staging, with no traffic, we go from
```
EXPLAIN ANALYZE SELECT COUNT ( * )
FROM spree_state_changes
WHERE spree_state_changes . stateful_id = 2024
AND spree_state_changes . stateful_type = 'Spree::Order';
Planning time: 0.142 ms
Execution time: 9.073 ms
```
to
```
EXPLAIN ANALYZE SELECT COUNT ( * )
FROM spree_state_changes
WHERE spree_state_changes . stateful_id = 2024
AND spree_state_changes . stateful_type = 'Spree::Order';
Planning time: 0.284 ms
Execution time: 0.202 ms
```
We realized in Spree v2.1 they follow this format instead and this is
what's causing issues to Katuma production.
This will remove the duplicate ones and convert the current preferences
to the new thus, keeping the values.
This is critical to debug bugs related to subscriptions.
Essentially, `has_and_belongs_to_many` doesn't give us the option for
any other column that the foreign keys themselves:
> A has_and_belongs_to_many association creates a direct many-to-many
> connection with another model, with no intervening model.
Source: https://guides.rubyonrails.org/v3.2/association_basics.html#the-has_and_belongs_to_many-association
Note however, that there's no way to update an order_cycle_schedule,
that I can think of but `updated_at` doesn't do any harm.
Activate paper_trail in order_cycles and schedules and track each others ids
An alternative way of doing this would be to use a gem for paper_trail associations but this way we avoid adding a new dependency to the app
It looks like this was probably changed whilst resolving a merge conflict somewhere. The number doesn't match the last migration file, and it's breaking the ofn-install CI build (as well as migrations on fresh servers).
