All fields with @dgraph directive

Users GraphQL
1

Hello,
Why GQL schema generates DQL properties like {Type}.{propertyName} in first place?
It potentially creates many indexes for “name” property for instance.
What is benefit of that behaviour?
What are risks of using @dgraph with propertyName (GQL creates such property in DQL schema, I checked) in two cases: 1) schema and db from scratch, 2) schema on existing db?

If default behaviour was creating property without type prefix, would not it be beneficial for example in case of inheriting properties from interfaces? Even interface from interface would be possible.

Some example:
GQLschema:

interface Thing {
	alternateName: String @search(by:[fulltext])
	description: String @search(by:[fulltext])
	id: ID!
	identifier: String @search(by:[fulltext])
	image: String @search(by:[fulltext])	
	name: String! @search(by:[fulltext])
	url: String @search(by:[fulltext])
}

type Product implements Thing {
	GTIN: String! @search(by:[hash])

	offers: [Offer!]
}

type Offer implements Thing {
	itemOffered: Product! @hasInverse(field: offers)
}

For now I have only product that can be offered. But let’s assume that according to https://schema.org/Offer it potentially in future can be also Service.
Then I would probably create another type and union or interface for both kinds of offerable thing.
The limit of interface is filtering.
If I create interface like this:

interface Offerable {
    offers: [Offer!]
}

then make Product and Service implement it and then change Offer’s itemOffered to be of type Offerable I cannot filter itemOffered for anything but id. Also there is a problem of moving property from from type to interface as property name remains the same (rewrite needed or @dgraph directive but it is not nice way). So in the case of filtering I need to choose union and resign from hasInverse.
But maybe I could live without hasInverse. In case of special searching/filtering I think I could use DQL.
But here comes a problem of properties names of types created in GQL. It would be confusing in case of some dynamic searching (need of storing property names for types) and even worse in case of dynamicly created properties (extending types which is is after all my goal).

2

Ping

3

There are several benefits to this convention. One main one is that you can have different types or search criteria for the “same” field name across different types. For example:

type A {
  name: String! @search(by: [term])
}

type B {
  name: Int!
}

If these were mapped to the same underlying Dgraph predicate, then this wouldn’t be possible. This lets you understand the full context of a GraphQL type by just looking at the type itself and you don’t have to worry about messing with the schema for type B if you updated the schema for type A.

And, there shouldn’t be a concern about having many indexes for different predicates. If you had the same indexes (say, term search) across A.name and B.name it’d the same amount of indexing stored in Dgraph.

A common use case for the @dgraph predicate is to take existing Dgraph schemas and provide the same access to that data via GraphQL.

4

If default behaviour was creating property without type prefix, would not it be beneficial for example in case of inheriting properties from interfaces? Even interface from interface would be possible.

And what do you think about that? As interfaces are really limited in the current shape.