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.
It's much clearer to read this way:
```
== OldMigrationsRemoved: migrating ===========================================
rake aborted!
StandardError: An error has occurred, this and all later migrations canceled:
You haven't updated your dev environment in a long time!
Legacy migration files before 2019 have now been removed.
Run `rails db:schema:load` before running `rails db:migrate`.
```
A migration's `up` method is only run when the migration needs to be
applied. The only case we could have a higher version number is when a
migration with a higher version got merged before the current one. And
in that case, we still want this migration to fail, because it hasn't
been applied yet.
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).
