GraphQL hasInverse, multiple 2-way edges in nodes (when both nodes can have multiple edges to each other))

type JobBoard {
  HAS_JOBAD: [JobAd] @hasInverse(field: HAS_JOBBOARD)
  ...
}

type JobAd {
  HAS_JOBBOARD: [JobBoard]
  ...
}

Would the two-way edges still work and be correct?
A job ad could be advertised on multiple job boards, such as seek, indeed etc.
These job boards can have multiple ads.

Maybe this will help. This is where I asked it being early on with my understanding with Dgraph.

2 Likes

I have tried out one-one, one-many and many-one two way linking, but never many-many link.

@MichelDiz, is it possible?

1 Like

It is.

An event can have many attendees and a Person can have many events attended. It works just like normal. Give it the hasInverse directive on either side and call it done.

2 Likes

It depends what you mean by many to many. In GraphDBs you can have several models of relations. In a graph DB, a node can point in any direction. Including to himself. You can also point N times to the same node using several edges. There are no limitations.

I think the one-one, one-many, many-one and many to many meanings in Graph Dbs are different from what we learn in relational DBs. We don’t have any issue to solve with many to many. Which is a solution for relational information in a DB that relies on Tables.

A “kind of many to many” relation, as it is done in relational dbs, can be mimic via “intermediary node”.

e.g:

User → intermediary → User

This intermediary would be a “bridge” that creates a very handful and informative many to many relationship. The objective of the “intermediary” is to abstract information. But you do not solve the same issue as it does in a SQL for example, just abstracting information in intermediary nodes.

3 Likes

This suffices until facets can be brought into GraphQL :crossed_fingers:

I don’t personally think that facets will make it into GraphQL spec though because of the lack of support across the GraphQL spectrum. Having this NiM (Node in the Middle) aspect is best use case right now.

I am refactoring some of our schema to take a dozen Person <> Person relationship type edges and combining them into a single relationship edge with added attributes. Interfaces can help make these NiMs easier to scale and maintain. Hoping to have Unions soon too.

2 Likes