fix: unexpected results when embedding the same table twice #4104
Conversation
| @@ -1138,7 +1148,7 @@ spec = do | |||
| { matchHeaders = [matchContentTypeJson] } | |||
|
|
|||
| it "ordering embeded entities with alias" $ | |||
| get "/projects?id=eq.1&select=id, name, the_tasks:tasks(id, name)&tasks.order=name.asc" `shouldRespondWith` | |||
| get "/projects?id=eq.1&select=id, name, the_tasks:tasks(id, name)&the_tasks.order=name.asc" `shouldRespondWith` | |||
There was a problem hiding this comment.
I didn't notice that we allow using the table name as filter even when the alias is present. This is the only test that mentions this, but I don't think this is expected, right?
From now on, this would fail with an error like:
GET /projects?id=eq.1&select=id, name, the_tasks:tasks(id, name)&tasks.order=name.asc{
"code":"PGRST108",
"details":null,
"hint":"Verify that 'tasks' is included in the 'select' query parameter.",
"message":"'tasks' is not an embedded resource in this request"
}If this change is OK then more info to the hint would be needed like: "If it has an alias, then use it instead of the resource name".
If using the resource name as well as the alias is expected, then this would be a breaking change and the solution would be different. Maybe throw an error when there may be ambiguity (like in #2529).
There was a problem hiding this comment.
From now on, this would fail with an error like:
This would also fail for filters, limits, etc.
There was a problem hiding this comment.
As long as you're only using one embedding for the same table, but with an alias, this is a working query right now. So, I'd say we only fix this in a major, otherwise people can't update to the latest patch without risking to break something that works.
steve-chavez
added
the
breaking change
Closes #4075
(In stand-by for a major release)