It's a code smell to have a boolean control argument.
`Permissions::Order` goes too far and assumes we want to filter out
canceled orders when using report's search params and this is not the
case.
This almost removes the responsibility of fetching orders from this
class, that has too many. Ideally, I'd go on and leave this up to the
caller of this class making `Reports::LineItems` rely completely on the
passed in `orders_relation`. Not today.
This model concerns helps us put together this related methods. Although
it doesn't provide any encapsulation yet, it makes a bit easier to
consider them all next time we need to change this implementation
somehow. It's a bit of an illusion but it feels like we are making this
God object model a bit smaller.
It also gives more room for documentation that will aid future devs.
This is quite hard and tedious due to its tight coupling with
Permissions::Order but sets the path to adding more of these and
eventually refactoring this class in the future.
This was initially intended to cache the result of the `#map` and
`#uniq` calls but we're not confident enough and don't want to
scopecreep this. It's still worth to point out that this is what we
need, line items' `unique orders`. Hopefully, next time we find a way to
optimize it.
This will log any N+1 it finds, pointing to the line causing it and
a way to solve it, aka. which `#includes` to add. Like so
```
web_1 | GET /admin/order_cycles.json?ams_prefix=index&q%5Borders_close_at_gt%5D=Sun+Jan+31+2021+00:00:00+GMT%2B0100+(Central+European+Standard+Time)
web_1 | USE eager loading detected
web_1 | OrderCycle => [:coordinator]
web_1 | Add to your query: .includes([:coordinator])
web_1 | Call stack
web_1 | /usr/src/app/app/serializers/api/admin/index_order_cycle_serializer.rb:41:in `coordinator'
web_1 | /usr/src/app/app/controllers/spree/admin/base_controller.rb:98:in `render_as_json'
web_1 | /usr/src/app/app/controllers/admin/order_cycles_controller.rb:17:in `block (2 levels) in index'
web_1 | /usr/src/app/app/controllers/admin/order_cycles_controller.rb:14:in `index'
web_1 | bin/rails:4:in `require'
web_1 | bin/rails:4:in `<main>'
```
We gave a try at Bullet long ago and abandoned it because it's not
a silver bullet (pun intended) due to false positives. However, it's
pretty clear that this won't happen often; we have endless N+1 still to fix.
I recently experienced how, relying on Bullet made it just extra 30s to fix
additional N+1s other than the one I was fixing. Usually, finding the
culprit line takes me more of 30min.
> This gem prevents Rails from auto-loading app code while it's running
migrations, preventing the common mistake of referencing ActiveRecord
models from migration code.
This will make us stop relying on @mkllnk to have robust data migrations
that don't cause trouble in the future.
The custom RSpec matchers they use raises the following deprecation
warning
```
Using `stub` from rspec-mocks' old `:should` syntax without explicitly enabling the syntax is deprecated. Use the new `:expect` syntax or explicitly enable `:should` instead. Called from /home/runner/work/openfoodnetwork/openfoodnetwork/spec/support/matchers/delegate_matchers.rb:22:in `block (2 levels) in <top (required)>'.
```
It's not worth maintaining those matchers to test such
implementation-related thing. Whether or not any delegations work is
something that will be caught by integration tests or directly stubbing
the collaborator object's methods.
This stems from
https://github.com/openfoodfoundation/openfoodnetwork/pull/6902.
