@hasInverse GraphQL to DQL mapping

[spinelsun (Or Chen)]

ok that’s good enough.
Another question abiut the gap between GQL and DQL,
when I use, for example, the @hasInverse directive and look in Ratel on the schema, I can’t see the @reverse index under the relvante predicate.
Can you tell why it doesn’t be reflected?

[amaster507 (Anthony Master)]

@spinelsun

when I use, for example, the @hasInverse directive and look in Ratel on the schema, I can’t see the @reverse index under the relvante predicate.
Can you tell why it doesn’t be reflected?

This is done purposefully. @hasInverse is not the equivalent to adding the @reverse directive in DQL. On the graphql schema, the @hasInverse directive creates logic in the resolvers to add/update/delete the inverse edge of the specified type. There is more to the underlying reasoning behind this but overall it is to allow for better type notatation predicate control. In DQL a single predicate can be applied between two types, but in GQL, if a Post Type has an author predicate and a Author Type has a hasPosts predicate, and they are linked with the @hasInverse, then the logic links Post.author <-> Author.hasPosts. In DQL this would be controlled without really specifying the edge on the opposite and assigning the @reverse which allows you to query with the ~ syntax such as ~author

---

This seems to be a common topic here in this community. @core-devs Is there any work for documentation that explains more of the differences like this between DQL and GQL? So far all I am seeing is:

How GraphQL works within Dgraph - Graphql

Dgraph is a GraphQL database. That means, with Dgraph, you design your application in GraphQL, you iterate on your app in GraphQL and, when you need it, you scale with GraphQL. You design a set of GraphQL types that describes your requirements. Dgraph takes those types, prepares graph storage for them and generates a GraphQL API with queries and mutations. You design a graph, store a graph and query a graph. You think and design in terms of the graph that your app is based around. Let’s l…

GraphQL on Existing Dgraph - Graphql

How to use GraphQL on an existing Dgraph instance. If you have an existing Dgraph instance and want to also expose GraphQL, you need to add a GraphQL schema that maps to your Dgraph schema. You don’t need to expose your entire Dgraph schema as GraphQL, but do note that adding a GraphQL schema can alter the Dgraph schema. Dgraph also allows type and edge names that aren’t valid in GraphQL, so, often, you’ll need to expose valid GraphQL names. Dgraph admits special characters and even differen…

And the docs for @hasInverse and @reverse don’t really help explain why the one is not equivalent to the other:

Links in the Graph - Graphql

All the data in your app forms a GraphQL data graph. That graph has nodes of particular types (the types you define in your schema) and links between the nodes to form the data graph. Dgraph uses the types and fields in the schema to work out how to link that graph, what to accept for mutations and what shape responses should take. Edges in that graph are directed: either pointing in one direction or two. You use the @hasInverse directive to tell Dgraph how to handle two-way edges. One-way…

@diggy

Reverse Edges

A graph edge is unidirectional. For node-node edges, sometimes modeling requires reverse edges. If only some subject-predicate-object triples have a reverse, these must be manually added. But if a predicate always has a reverse, Dgraph computes the reverse edges if @reverse is specified in the schema.

The reverse edge of anEdge is ~anEdge .

For existing data, Dgraph computes all reverse edges. For data added after the schema mutation, Dgraph computes and stores the reverse edge for each added triple.

[Raphael (Raphaël Derbier)]

The documentation has a section on GraphQL - DQL interoperability where we try to capture what would be useful for a developer.

You don’t see @reverse in Ratel on the DQL schema when you have used @hasInverse in GQL simply because we are not using @reverse to implement the @hasInverse behavior.

I’d like to better understand your developer use case here so we can update the documentation.
We would like the doc to be use case oriented instead of explaining a design decision.

What are you trying to achieve that led you to use @hasInverse in GQL and try DQL queries on the same data? That would help improve the “GraphQL - DQL interoperability” section. (You can push a PR to the doc too).

@amaster507 explained it well
in GQL if you have
Post --has_author–> Author
and
Author --writes–> Posts
Author --likes–> Posts
Author --reviews–> Posts
When you create a Post with an Author, what is the “reverse” link to create: ‘writes’ ‘likes’ or ‘reviews’.
You need a way to specify that the reverse of “has_author” is “writes”. The “simple” reverse predicate in DQL is not a solution.

That said, you can use the @dgraph predicate as explained in GraphQL on Existing Dgraph - GraphQL dql to tweak the mapping between GQL and DQL. But that is an advanced use case only if the standard approach cannot cover what you want to do.