"Edge-key" functions vs "Edge-value" functions

[pmualaba]

There is an interesting discussion going on disscuss.dgraph.io which leads to this Github issue:
https://discuss.dgraph.io/t/migrating-away-from-generic-type-edge-in-our-app-plus-modeling-complex-schema/2107/8

Since Dgraph added mutations, Dgraph documentation also changed the ideal datamodeling technique for edge organization. Moving away from organizing your edges into a few "super edges" to organizing them in many "namespaced edges". (specialization over generalization)

This switch is getting adopted by the Dgraph community but this also leads to the arising of the need to be able to wórk with these "namespaced edges" in GraphQL+-. Which can now only be done using the "facet label workaround" technique, which is discussed in the above post. What we need are optimized Dgraph native "Edge-key" functions. Adding a few utility functions on edge keys (instead of edge values) to GraphQL+ -

An example implementation of this idea could look like the following:

Default “edge value” function works like this:

me(func: eq(person.name@en, "Steven Spielberg")) @filter(has(director.film)) {
  person.name@en
  director.film
  initial_release_date
}

Why not add the following “edge key” functions:

me(func: eq(startsWith(person. as _:p), "Steven Spielberg")) @filter(has(startsWith(director. as _:d))) {
  _:p
  _:d
  initial_release_date
}

me(func: eq(endsWith(.name@en as _:n@en), "Steven Spielberg")) @filter(has(endsWith(.film as _:f))) {
 _:f
  name@en : _:n@en
  initial_release_date
}

me(func: eq(contains(name as _:n), "Steven Spielberg")) @filter(has(contains(director as _:d))) { 
  _:d
  name : _:n
  initial_release_date
}

me(func: eq(regexp(/^person/ as _:p), "Steven Spielberg")) @filter(has(contains(director as _:d))) { 
  _:d
  _:p
  initial_release_date
}

The "blank" variables _:d, _:p, _:n would then automatically be resolved to their "fully-qualified-namespaced-edge name" in the response.

This way we can indeed performing OR queries across different predicates by grouping the predicates again which were originally distributed by their namespace.

Then we can easily do a grouped ".name" edge query across namespaced edge keys like "person.name", "pet.name", "object.name", ... (without the need to attach a "name" edge to every instance)

Or implement class inheritance hierarchies: nodes with edges "type.person.teacher", "type.person.student", "type.person.client", ... can then be queried for "type.person" to return all nodes which are of type person.

Or... many more use cases can profit from having access to native "edge-key functions" in GraphQL+-

[manishrjain]

We don't have any plans to support this and haven't come across convincing use cases where we need it.