Moved from GitHub dgraph/5624
Posted by MichelDiz:
Experience Report
What you wanted to do
Based on #2277 #2863
I would like to avoid issues related to Types.
What you actually did
n/a
Why that wasn’t great, with examples
Some users forget to add <dgraph.type> to the dataset and this prevents some basic operations (e.g delete and “expand all”) from occurring. Adding strict mode would prevent errors like that.
Enforce a strict schema by setting --mutations strictType.
strictType: Instead of being based on the schema, it will enforce the mutation based on the Type coming from the dataset/mutation via <dgraph.type> predicate. It will check if the type exists and infer the mutation against the Type definition. Will throw an error if the mutation has not <dgraph.type> predicate or the Type doesn’t exist.
Making mandatory give the type and the type have to exist in the Type definition.
Update
strictAll: This implements the strictType by making edges also constrained by type. If a mutation has an edge which points to an unrelated entity. It will throw an error.
Dgraph Schema should have a way to tell that a Type is related only to N types. e.g. an edge “owns_pet” should only accept animal types. Not cars or objects.
Reference Dgraph for rdfs domain and range?
Optional
autoType: It will add <dgraph.type>automatically based on the mutation structure. It is mandatory to defined a Type Definition. Dgraph will infer the mutation and based on the predicates it will accept and add the Type found. If the mutation has a different predicate than any other Type Definition. It will throw an error and deny the mutation.
e.g:
-
- The mutation has only 3 predicates. Dgraph finds the three predicates in the “User” Type, but the User Type has 10 predicates. Even so, Dgraph adds the Type “User”.
-
- The mutation has only 4 predicates. Three predicates are under “User” Type, but one is found under “Object” Type. Then Dgraph throws an error and denies the mutation.
This can be tricky, as there may be cases where several Types share the same predicate. It can become a mess. if someone has a solution. It would be nice. Maybe use the “namespacing” approach.
And it would also have a tradeoff in case of CPU usage. Perhaps it is the same tradeoff of having “Strict mode” per scheme.