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>
ghost
closed this as
|
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
anyOfcontainstrueand the id exists. Removing the links stuff returns the one contract as expected{ "type": "object", "properties": { "id": { "const": "b681c25a-7bd9-4b24-b2cc-c540287c8950" } }, "anyOf": [ { "$$links": { "was built into": { "type": "object", "anyOf": [ { "$$links": { "was built into": { "type": "object", "anyOf": [ { "$$links": { "was built into": { "type": "object" } } }, { "$$links": { "was merged as": { "type": "object" } } }, true ] } } }, { "$$links": { "was merged as": { "type": "object" } } }, true ] } } }, { "$$links": { "was merged as": { "type": "object" } } }, true ] }The text was updated successfully, but these errors were encountered: