Add breaking test to cover double join errors #512
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The specs in this PR adds specs that show specific untested conditions that give raise to a table being joined twice in the same query.
After trying to upgrade to Rails 6, many segments and filters stopped working and we were trying to find the root cause, when we bumped into what seems to be a performance issue in Forest Rails.
To explain what we have found, whenever we try to do an operation that would end up filtering and including an association, i.e. having a field from an associated model in both filter and sort, the query builder ends up double joining the same table, with different aliases, which cost considerably in query performance, doubly so if the table is connected through a
has_one through:
relationship.By building a similar query using only ActiveRecord, we wouldn't have this issue (
Island.eager_loads(:location).where(location: { id: 1 })
). So, looking down the code we have found out that the current use of ArelHelpers library, together with Rails 6.1 table memorization is probably the cause. This sequence of calls that was derived from the filter parser plus resources getter demonstrates the issue:PS: In our specific use-case, the situation is a bit worse than just a performance hit. One of our tables has its name hardcoded (not derived from the class name) and this causes the issue to escalate and give a PG::DuplicateAlias error when the double join of the issue above occurs.