That leads to another question I asked you once about implementing 2 interface with the same fields.
I have some other types that implement both IObjectArtifact and IArtifact.
If I’ll add an ID for both of them what will happen?
What is the current behavior that you observe when you add an ID to both of them? If it doesn’t work for you, then we can add a quick fix where if the ID! field name is the same for two implementing interfaces, we should allow it.
At present, a field in an interface is stored in Dgraph using interfaceName.fieldName predicate, irrespective of which types implement that interface. That particular strategy solves a lot of problems with respect to interface handling in GraphQL on top of DQL.
For example, in your case, you have following schema:
type IArtifact {
IArtifact.orkId
...
}
IArtifact.orkId: string @index(hash) .
type ScriptArtifact {
ScriptArtifact.arguments
ScriptArtifact.inputs
ScriptArtifact.output
}
...
So, if there are multiple interfaces with the same field name and a type that implements all those interfaces, then there would be a problem: in which predicate to store the data for the type objects?
Example:
That means type T has only two fields f1 & f2. But, while adding data for type T, which predicate to use to store the data for f1: I1.f1 or I2.f1? That is a problem.
This is not a problem with ID, because that maps to uid in Dgraph, and so is not stored as a predicate.
@abhimanyusinghgaur I understand.
It seems like a something that is similar to the Deadly Diamond of Death problem.
In python they solved it by taking the field of the first Inherited interface/class.
Maybe you can take the same approach?
The problem with using the field of the first inherited interface would be that the other interfaces won’t find that field in the type. That won’t be the expected behavior from a user’s perspective. Whether I query f1 using I1 or I2, I should always get it on objects of type T. If I use I1.f1 for storage, I won’t get f1 when I query it using I2.
On the other hand, if we were to use T.f1 as the predicate name for the inherited field, then we will no longer have the Diamond inheritance problem. But, that would introduce a lot of complexity in the GraphQL layer.
So, I would instead suggest not to have a design that can cause such problems, if possible.