What does "reference to ... changes the interpretation of ... elsewhere in the query" mean in context of ordered properties?

[isidentical]

I felt like the message isn't explicit about 'elsewhere', since I still can't see what it is changing. Here is the query and schema;

SELECT
    ast::Tuple{lineno, col_offset, end_lineno, end_col_offset, _module: {filename}}
FILTER
    count(.elts) = 3
    AND (
        WITH __item_2_0 := (SELECT .elts ORDER BY @index OFFSET 2 LIMIT 1)[IS ast::Call]
        SELECT (
            WITH __item_0_0 := (SELECT __item_2_0.args ORDER BY @index OFFSET 0 LIMIT 1)[IS ast::Name]
            SELECT __item_0_0.py_id = 'lol'
        )
    )
    LIMIT 10;

I have a select, within a select at this line, I get that error;

error: reference to '__item_2_0' changes the interpretation of '__item_2_0' elsewhere in the query
  ┌─ query:8:65
  │
8 │             WITH __item_0_0 := (SELECT __item_2_0.args ORDER BY @index OFFSET 0 LIMIT 1)[IS ast::Name]
  │                                                                 ^^^^^^^ error

If I remove ORDER BY @index in the sub-query, the error disappears and query works as expected, any idea on what is happening?

[elprans]

The error message and the diagnostics need work, for sure.

Here's what's going on. In EdgeQL, path expressions are lookups on a graph of objects. So, when you write Call.args, you mean "give me a set of arguments objects that is reachable from a given set of Call objects via the args link".

To illustrate, imagine you have this object graph:

[Call1]  ---> [arguments1]
            
[Call2]  ---> [arguments2]
                   ^
[Call3]  ----------|

Then, Call.args would return a set of two elements {arguments1, arguments2}. But here there are three links pointing to the two objects. And so if you attempt to sort the result set by a link property, there is no meaningful way to perform that operation, because there may be multiple links pointing to the same object in the result.

So what you want instead here is to iterate over the Call set explicitly so that there is no graph ambiguity, because you'll be treating each Call -> arguments relationship one by one:

FOR call IN {__item_2_0} UNION (SELECT call.args ORDER BY @index) 

Now, you might object that __item_2_0 is already a singleton due to LIMIT 1 earlier, and you'd be right: this check isn't smart enough yet to take that into account.

[isidentical]

Thanks so much for the detailed reply!

[Soulmate69]

Get it fixed