[Convex Ents] Asymmetrical self-directed 1:many edges

Is that possible with Convex Ents? doesnt see it in the docs. Point is that I want a reply functionality. Which means that there is one message that replies to another (asymmetrical) but you can only reply to one message. But one message can be replied to by many messages.

lee•8/17/24, 3:09 PM

The docs say

Every edge has two "ends", each being an Ent. Those Ents can be stored in the same or in 2 different tables.

So it sounds like "self-directed" edges are possible. However, there is a slight problem: you probably don't want to require every message to be a reply to some other message (that would require infinite messages or a cycle of replies). You want an optional 1:many edge, which is not possible

Making the singular end of the 1:many edge optional is not supported for now.

https://github.com/xixixao/convex-ents/issues/5

To work around this, you could use foreign references directly, so each message has a

GitHub

1:many edges require single cardinality end to be required · Issue ...

This will require more configuration, especially for cascading deletes. We'll hold off on adding this until we get people asking for it.

FleetAdmiralJakob 🗕 🗗 🗙OP•8/17/24, 4:06 PM

Thank you so much. I will try the workaround with putting the id directly into the field

Matt Luo•8/17/24, 4:16 PM

I think the hard thing about putting the ID directly in the field is that to do joins, I don't think you can use Ents.

My understanding is that you could use vanilla Convex to do the join - but then you'd include the table to Pick and you'd always use vanilla Convex for that table.

Maybe there is a way to keep the table defined as an Ent, but still use vanilla Convex or convex-helpers' relationships, but I haven't tried it personally

FleetAdmiralJakob 🗕 🗗 🗙OP•8/17/24, 4:46 PM

Hmmm, I think about it and share my research

MMatt Luo I think the hard thing about putting the ID directly in the field is that to do ...

ampp•8/18/24, 8:02 AM

I would think you could use ents, couldn't you just do this within the loop of results via map? I think i'm unaware if any benefit exists using convex helpers.

ampp•8/18/24, 8:04 AM

I went with ents so early on i never had any complex relationships with vanilla

Llee The docs say > Every edge has two "ends", each being an Ent. Those Ents can be ...

FleetAdmiralJakob 🗕 🗗 🗙OP•8/18/24, 8:21 AM

Hi, if I try to set up the field like this:

I get this error:

FFleetAdmiralJakob 🗕 🗗 🗙Hi, if I try to set up the field like this: ```ts .field("replyTo", v.id("...

ampp•8/18/24, 8:29 AM

field("replyTo", v.optional(v.id("messages")))

ampp•8/18/24, 8:31 AM

it happens

FleetAdmiralJakob 🗕 🗗 🗙OP•8/18/24, 8:33 AM

So seems to work:

schema:

query:

ampp•8/18/24, 8:33 AM

im actually working on our chat thing rn, i use v.union(v.id('messages'), v.null())

FleetAdmiralJakob 🗕 🗗 🗙OP•8/18/24, 8:34 AM

what is the benefit of over

ampp•8/18/24, 8:36 AM

my understanding is if you were loading stuff from the ui, null is helpful to let you know if the data loaded empty, with undefined, it hasn't loaded yet. so its not as confusing

FleetAdmiralJakob 🗕 🗗 🗙OP•8/18/24, 8:37 AM

ok, hmmm, yeah

ampp•8/18/24, 8:38 AM

apparently the more code i write the more im letting nextjs do lots of small queries.

FleetAdmiralJakob 🗕 🗗 🗙OP•8/18/24, 8:39 AM

https://www.youtube.com/watch?v=YYkOWzrO3xg

YouTubeHoigim Dang

Null References The Billion Dollar Mistake

lecturer：Tony Hoare
conference：QCon London 2009
topic：null reference in programming language design

ampp•8/18/24, 8:43 AM

yeah null with c is a totally different game. our dx protects us from

Matt Luo•8/18/24, 2:13 PM

Thanks for sharing the approach to query directly in the replyTo property:

Do you prefer this approach over creating a asymmetrical self-directed many:many relationship between messages?

https://labs.convex.dev/convex-ents/schema#asymmetrical-self-directed-manymany-edges

Ent Schema - Convex Ents

Relations, default values, unique fields and more for Convex

MMatt Luo Thanks for sharing the approach to query directly in the replyTo property: ```t...

FleetAdmiralJakob 🗕 🗗 🗙OP•8/18/24, 11:21 PM

The thing is that I don't want many to many relations. I want that you can only reply to one message. many to many would mean that one message can reply to multiple messages

FleetAdmiralJakob 🗕 🗗 🗙OP•8/18/24, 11:22 PM

With my method you can only insert one message to reply to

Matt Luo•8/18/24, 11:26 PM

Yeah, your business logic wouldn’t include many to many. I believe Michal wrote to do many to many as a workaround to the limitation of not being able to do an optional one to many.

Maybe I need to re-read this whole post. I think when you first made this post, you were looking for an optional one:many, and then the post title got edited to the asymmetric self referencing. So maybe what I’m saying is no longer relevant .

FleetAdmiralJakob 🗕 🗗 🗙OP•8/18/24, 11:28 PM

It still needs to be optional. Not every message replies to another

FleetAdmiralJakob 🗕 🗗 🗙OP•8/18/24, 11:29 PM

You can write messages that don't reply

Matt Luo•8/18/24, 11:30 PM

Right, so
1) does the “followers” example from the Convex Ents docs work for this use case of replying?
2) if not, does a fake, but technically many:many junction table work better than this nested query approach you wrote?

Michal Srb•8/19/24, 6:13 PM

Recap:

Problem: One message can be a reply to 0 or 1 other message. 1 message can have many replies.

This is an assymetrical, self-directed, optional 1:many edge.

Not directly supported with Ents, but the workarounds are either:

Use a field as @FleetAdmiralJakob �� has done, and read the "parent" message manually. Most likely you will want to index the field so that you can get a query for replies of message X. This is the cheapest approach, works well, and is what you'd do in vanilla Convex as well.
Use a many:many edge. Enforce the uniqueness when writing a reply. Then the "reply" relationship will be stored in a separate table.

Here I'd probably recommend sticking with the first approach, unless you see a possibility of the edge changing from 1:many to many:many in the future.