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 query object currently does not recognise the primary key as being present if it's in the form of
other_column AS primary_key
. This is not usually an issue, but if the query joins a table that has a column with the same name as the primary key (quite likely if the primary key is calledid
) then it becomes impossible to run the query without getting an "ambiguous column" error.This makes it impossible to do sorting or filtering of objects by related tables, which was an inconvenience when we were using Analogue to get paginated lists of users.
This pull request changes the logic in
Query::enforceIdColumn
. It was checking for a column whose name was exactly equal to the primary key, and adds it if it was not found. It now checks for a column that ends with the primary key name, and then checks that it is a valid alias. The performance impact in the usual case (no aliasing) should be minimal.I have also changed the automatically inserted id column from being
primary_key
totable.primary_key AS primary_key
, to avoid the situation mentioned above happening with the automatically added identity column.A test for this case has been added to
QueryTest
.