There are some N+1 queries in the app, and for detecting this we use the bullet gem in the development_app.
The problem with this approach is that it is too manual (i.e. a developer need to be in this page and need to see the error in the log and so on).
As an alternative way of handling this, in one of our last maintainers meeting we've talked about integrating this gem in our Continuous Integration pipeline (GitHub Actions). With this change, if we don't eager load these kinds of queries, we would have a failing spec that we can fix (and prevent reintroducing when refactoring and so on)
More information on how to actually do this on bullet docs: https://github.com/flyerhzm/bullet#run-in-tests
Technical implementation
This would mean to change this method and the generator, so we also have the --profiling in the generated test_app and that the bullet initializer configuration also applies to the test_app.
|
task :generate_external_test_app do |
We should probably use also the unused_eager_loading_enable as sometimes it gives positives because some resources don't use this association, but it's used in other resources. This is the case on proposals that might not have a category but that actually have a category on other proposals and so on.
This was already implemented in the past, but for some reason we've lost it: #138
There are some N+1 queries in the app, and for detecting this we use the
bulletgem in thedevelopment_app.The problem with this approach is that it is too manual (i.e. a developer need to be in this page and need to see the error in the log and so on).
As an alternative way of handling this, in one of our last maintainers meeting we've talked about integrating this gem in our Continuous Integration pipeline (GitHub Actions). With this change, if we don't eager load these kinds of queries, we would have a failing spec that we can fix (and prevent reintroducing when refactoring and so on)
More information on how to actually do this on bullet docs: https://github.com/flyerhzm/bullet#run-in-tests
Technical implementation
This would mean to change this method and the generator, so we also have the --profiling in the generated
test_appand that the bullet initializer configuration also applies to thetest_app.decidim/decidim-dev/lib/tasks/generators.rake
Line 23 in 0386602
decidim/decidim-generators/lib/decidim/generators/install_generator.rb
Line 154 in 0386602
We should probably use also the
unused_eager_loading_enableas sometimes it gives positives because some resources don't use this association, but it's used in other resources. This is the case on proposals that might not have a category but that actually have a category on other proposals and so on.This was already implemented in the past, but for some reason we've lost it: #138