It turns out that we were executing `DatabaseCleaner.clean` on two
`after(:each)` blocks. One for all specs and another one for `js: true`
specs. As a result feature specs were hitting both which slows them down
considerably.
On my machine this changes consistently saves 2sec on
`spec/features/consumer/shops_spec.rb` but chances are it has an
accumulative effect when run on the whole test suite.
I feel embarrased that this is the second follow up of my last
migration: https://github.com/openfoodfoundation/openfoodnetwork/pull/3126
The last migration didn't change any database structure, but the schema
still needs the latest migration version. Otherwise it will display
pending migrations when setting up the database.
This commit allows to run `bundle exec rake db:reset` in development
without the following message:
Run `rake db:migrate` to update your database then try again.
You have 1 pending migrations:
20181123012635 AssociateCustomersToUsers
The next pull request with a migration would have solved this problem as
well.
This totally removes the following N+1 query from the GET /shops request
```sql
SELECT "spree_properties".* FROM "spree_properties"
INNER JOIN "spree_product_properties"
ON "spree_product_properties"."property_id" = "spree_properties"."id"
INNER JOIN "spree_products"
ON "spree_products"."id" = "spree_product_properties"."product_id"
INNER JOIN "enterprises"
ON "enterprises"."id" = "spree_products"."supplier_id"
WHERE "spree_products"."supplier_id" = 24;
```
The product properties of the corresponding enterprises are now loaded
in a single query fired from the controller.
This totally removes the following N+1 query from the GET /shops request
```sql
SELECT "spree_properties".* FROM "spree_properties"
INNER JOIN "producer_properties"
ON "spree_properties"."id" = "producer_properties"."property_id"
WHERE "producer_properties"."producer_id" = 17
ORDER BY producer_properties.position;
```
The producer properties of the corresponding enterprises are now loaded
in a single query fired from the controller.
Using Marshal.dump on the French production database raised an error:
Encoding::UndefinedConversionError: "\xC3" from ASCII-8BIT to UTF-8
Replacing Marshal with YAML solves the problem. It is also more reliable
and human readable.
This code was run against the French, Australian and UK production
data successfully.
