-
Notifications
You must be signed in to change notification settings - Fork 3
Optional links query doesn't return anything #1128
Comments
@Ereski I think we had talked about something similar before, so this might be a dup, but I couldn't find the relevant issue |
@Hades32 this is the same query as the another issue you opened regarding PG erroing out due to long identifiers? Seems like it's closed now? |
@Ereski IIRC the one with long identifiers just errored out. This one returns an empty results array |
I can't find that issue. Guess it got deleted when jf went public. The query looks ok, I'll take a closer look 👍 @Hades32 Just FYI, |
@Ereski turns out this is preventing the graph at https://jel.ly.fish/check-run-719ae387b67014dce33976fb299fe940f4d8dccf (and a few others. Not sure yet, what the pattern is) to show up. |
@Hades32 for this specific card, what's the relevant part of its link graph for the query? Which links exist and which don't? |
@Ereski the first level of |
@Hades32 just to confirm, it's something like this: The root (id:
Correct? |
exactly @Ereski |
Reproduced. Gonna take a closer look at the query |
The query looks fine 🤔 |
It works if I remove the middle |
SQL is just a bunch of left joins and the only constraint is the root card ID 🤔 |
I'm stumped @Hades32. Not sure what's going on here. The only differences I can see so far are things that don't matter. |
Then it must be really bad :/ |
Locally. I wrote a test. I'm now wondering if the left joins are interacting in a weird way. Gonna run some tests monday. Do you know of any other query we currently have with an optional link inside another optional link @Hades32? |
@Ereski I can't think of any that exist right now |
Reduced to: {
type: 'object',
properties: {
id: {
const: "b681c25a-7bd9-4b24-b2cc-c540287c8950",
}
},
$$links: {
'was built into': {
type: 'object',
anyOf: [
{
$$links: {
'was built into': {
type: 'object',
anyOf: [
{
$$links: {
'was built into': {
type: 'object',
},
},
},
true,
],
},
},
},
true,
],
},
},
}, |
So far it seems the requirement is: at least three levels of |
Yep, I think I found the problem. The part of the query that builds a full JSON object from a list of link edges doesn't seem to deal very well with a corner case when aggregate functions are used with left joins that return no matches. Only happens with two nested, optional |
The subquery that builds the final contract tree when querying with links uses an inner join to get the nested link. Roughly: ``` JOIN ( // Build the linked contract... ) AS linked ON edge.source = linked.id ``` These joins are nested in the case of nested links and there is a toplevel `LATERAL`. In the case of two nested optional links, the `LATERAL` subquery looks roughly like this: ``` FROM cards, LATERAL ( // ... JOIN ( // ... ) AS linked ON edge1.source = linked.id // ... ) WHERE edge0.source = cards.id ``` If the optional contracts don't exist, `linked.id` will be null and the `edge1.to = linked.id` condition will fail. As a consequence, the whole lateral will be empty and so will the result. The fix is change those inner joins into left joins. This is a tentative fix because I have fuzzy memories of making this exact change and causing unrelated tests to fail. Fixes #1128 Change-type: patch Signed-off-by: Carol Schulze <carol@balena.io>
The subquery that builds the final contract tree when querying with links uses an inner join to get the nested link. Roughly: ``` JOIN ( // Build the linked contract... ) AS linked ON edge.source = linked.id ``` These joins are nested in the case of nested links and there is a toplevel `LATERAL`. In the case of two nested optional links, the `LATERAL` subquery looks roughly like this: ``` FROM cards, LATERAL ( // ... JOIN ( // ... ) AS linked ON edge1.source = linked.id // ... ) WHERE edge0.source = cards.id ``` If the optional contracts don't exist, `linked.id` will be null and the `edge1.to = linked.id` condition will fail. As a consequence, the whole lateral will be empty and so will the result. The fix is change those inner joins into left joins. This is a tentative fix because I have fuzzy memories of making this exact change and causing unrelated tests to fail. Fixes: #1128 Change-type: patch Signed-off-by: Carol Schulze <carol@balena.io>
Unfortunately, it doesn't seem like this fixed the issue. Neither https://jel.ly.fish/check-run-697118058f5b4e4d962e38325137e40ff6655578 nor https://jel.ly.fish/check-run-719ae387b67014dce33976fb299fe940f4d8dccf are showing a graph, as the query returns empty. Tested on JF v42.2.73 which includes core v8.2.7 |
Something is wrong. JF shouldn't even compile with any core version higher than 8.2.0. |
The below query doesn't return anything although the
anyOf
containstrue
and the id exists. Removing the links stuff returns the one contract as expectedThe text was updated successfully, but these errors were encountered: