`eq` function not behaving as expected

So let me try to fill in some missing context. First if you have not yet, check out this reference:

So beyond that, GraphQL both the schema, queries, and mutations get rewritten into DQL and then processed.

Since GraphQL schema does not really handle the case of a predicate used by multiple types (outside of interfaces) it is possible that two predicates of two different types could be totally different. You could for instance have:

type Foo {
  name: String @search(by: [term])
  list: [Bar]
}
type Bar {
  name: String @search(by: [exact])
  list: [String]
}

So if Foo: name and Bar: name both mapped to just the predicate then it would have to be able to be indexed differently for each type. And as is illustrated with the Foo: list and Bar: list. The predicate types might not even be compatible across types. So to allow this unique predicate for each type and help distribute predicates in the cluster any GraphQL type field definitions that are not specifically mapped to a predicate using the @dgraph directive are automatically mapped to a dotted notation field indication what type the field belongs to. (A little gotcha when dealing with interfaces is the interface fields get mapped to the interface dotted predicate, not the type dotted predicate.

I understand being hesitant to dig into the RDF and DQL aspects, but when you cross that barrier you will wonder why it seemed so hard before to understand and why other graph databases aren’t doing things the same way.

On a side note about the terminology in Dgraph, they seem to take a more literal and fundamental meaning of the words. This probably arose from dealing with ESL developers and developing across language barriers. What exactly is an object and a property anways compared to what is a node and a predicate.

2 Likes