I agree that a library could help mitigate this issue, however for my purposes this will not be sufficient. The records we are storing in Dgraph are for reporting purposes. We are returning aggregates from these nodes, and because of the way that variables and aggregates work in Dgraph. A library for de-serialization would help if we were returning the raw data, but we are not.
I need a way of guaranteeing that a particular relationship will never be violated while never (or very rarely) actually returning the raw nodes. I understand this can be done in the query, and that the views expressed here are that Dgraph should be capable of running in a schema-less fashion. I do not believe that my proposed change would violate this.
I’m going to do my best not to misrepresent bennyrio. Apologies ahead of time if you feel I have.
Quoting:
In a sense, just like RDF, dgraph is schema-less, CMIIW, schema in dgraph is just type safety compared to schema in SQL, we can have dgraph database without even having a schema, but it will be a bit verbose because we need to add RDF type in every mutation.
Part of a type includes whether or not it is an array. I think this is actually arguing for my proposal. The type of []string is not the same as a type of string. What I’m proposing would differentiate between a type of []uid and uid. As far as I can tell there should not be a difference here. The rest of my proposal is derived from this initial assumption.
So if we assume that Dgraph should be able to establish, enforce, and differentiate between []T and T where T is any supported type (string, int, etc), why shouldn’t Dgraph also do this for the difference between []uid and uid?
I guess the real confusion I have is that Dgraph establishes as difference between []T and T for all datatypes except for uid. Why is uid not treated as all the other data types are?