fix: dont mistake non-key access with foreign key #642
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.
Consider this two path expressions:
classrooms.classroom.ID, classrooms.classroom.name
While the first path could be optimized to
classrooms.classroom_ID
, the second path is not a key access and hence must be transformed toclassroom.name
, whereclassroom
is the nested join node, refer to this example:As both paths navigate through the same join nodes, we do not (yet?) optimize the first path to the foreign key, but access the
ID
in the target ofclassroom
. This is also the behavior of thecds-compiler
and should not matter too much as the join node is produced through the second path anyway:The problem was, that when we found the second path, we have already seen this path up to the
n - 1
step before, and only the reference for the first path was adjusted to not be a foreign key access anymore.fixes cap/issue#16001