Is it possible to recursively query links?

[jonaird]

Let's say I want to query for a particular post, all of the posts comments, all of the comments on those comments etc. Is this possible or do I need to change my schema to achieve this?

[elprans]

There's no syntax for recursive traversal currently, although there is a plan to implement it eventually.

[AnsonHwang86]

another upvote

[Arrow7000]

Hey @raddevon, since 4.0 seems to be around the corner I wanted to check if this feature made it in by any chance? 🙏

[raddevon]

It won't ship in 4.0. Track this issue for updates on it: #4168

[matejuh]

For us it's a hard stop for evaluation Edgedb. Although rest of features seems interesting, we have recursive query as a primary use-case.

[lowjiajin]

Same. It’s not encouraging that the linked issue has had no substantive update for more than a year too. Is there a tentative roadmap that puts this for any future release (however far), or is this feature too low priority for that?

[CodesInChaos]

The best workaround I can think of is including a multi-link to all of its ancestors in each node. That's easy to compute (parent's ancestor set plus parent node itself) and existing nodes don't need to be updated when adding new nodes.

Model:

type Node {
    name: str {
        constraint exclusive;
    }
    parent: Node;
    multi ancestors: Node;
}

Insertion:

with
    parent := (select Node filter .name = "1")
insert Node {
    name := "1.1",
    parent := parent,
    ancestors := assert_distinct(parent union parent.ancestors),
}

[CodesInChaos]

Changing the parent of an existing node is expensive with that design, adding new children while keeping the existing tree unchanged is cheap. But I don't think you need to do it client-side, since you can use the denormalized ancestor set to find all descendants of the node in question with a simple non recursive query.

For the OP's use case of comment threads, I'd expect changing the parent to happen rarely if ever (moderator re-homing a thread). If that assumption doesn't hold, this design might not be the right choice. Space requirements also scale quadratic with tree depth, so it's not suitable for very deep trees either.

[adriangb]

Totally makes sense. Thank you for confirming and going in depth. My use case would require constant moving of subtrees from one node to another, so this solution isn't great for me (in theory, in practice it may be fast enough anyway).

[davepies]

The best workaround I can think of is including a multi-link to all of its ancestors in each node. That's easy to compute (parent's ancestor set plus parent node itself) and existing nodes don't need to be updated when adding new nodes.

Thanks @CodesInChaos, that is a good idea and would work in my case.

I am just not sure how the schema / query would look like to model this. Any hints would be highly appreciated :)

[Arrow7000]

Hi, I'm trying to implement the approach here for a messaging application, but running into a problem. My schema:

type Message {
    required property name -> str;
    required property content -> str;
    required property timestamp -> datetime;

    # What this message is a reply to (if it is a reply)
    link replyTo -> Message;

    # This should return all the preceding messages in a reply thread
    multi link earlierReplies -> Message {
        default := distinct .replyTo union .replyTo.earlierReplies;
    }
}

But when I try to create a migration I get the error could not resolve partial path. Which I'm guessing is because apparently you're not allowed to reference self properties in a default expression? #3581 (comment)

Does this mean I can't automatically create the .earlierReplies field? Do I have to manually fetch them from the .replyTo message before I can create a new message and manually include them in the insert statement for a new message?

[CodesInChaos]

I think you can use a subquery in your insert statement to fetch the ancestors given the parent-message-id parameter