Closed MarianPalkus closed 7 years ago
A workaround might be something like this:
character.AddField("height", c => c is Human? (c as Human).Height : 0);
character.AddField("primaryFunction", c => c is Droid ? (c as Droid).PrimaryFunction : null);
Hi Marian,
Thanks for the detailed issue! One of these is definitely a bug - the parser was recognizing on
as a fragment instead of as a type condition. I just pushed a commit that should fix that.
However, in general this library does not yet support fragments with type conditions, inline or not. Right now it just does a dumb insertion of all the fields in the fragment into the selection set, then validates that against the selected type.
The reason we don't yet support type conditions is because they go hand-in-hand with inheritance, and inheritance is a hard problem when working with Queryable backends. For example, here are two possible ways you could write a query with inheritance:
db.Characters.Select(c => new {
Name = c.Name,
Height = ((Human)c).Height
})
db.Characters.Select(c => new {
Name = c.Name,
Height = c is Human ? (c as Human).Height : 0
})
Only one of those ways works with Entity Framework, and only one of those ways works with LINQ-To-Objects. Unfortunately, it's not the same one. This isn't an intractable issue, we already do provider sniffing elsewhere due to other inconsistencies, but it does add more effort.
The other issue is adding explicit support for inheritance in the schema. Right now all of the schema types are independent, with no relation to other types other than on their properties. With inheritance, that changes to having to do graph traversal to determine a single unifying type for a hierarchy. Again, not impossible, just a lot more work.
I've always planned to support inheritance at some point, but the difficulty vs. payoff has led to it being ranked pretty low in the list of priorities.
However, as you mentioned, it is possible to workaround by just defining all the types on the base type (e.g. Character
). This is not ideal since it's not really following the spec, but I think that at least makes it usable for queries against a model that utilizes inheritance.
Ok, thanks a lot for clearing this up.
Great project, thanks for your work 👍
I am trying to implement inline fragments with type conditions analogous to the sample of the official graphql docs graphql docs.
Basically, there is an interface or base type (
Character
) and two concrete types (Human
andDroid
), the types are slightly modified for simplicity:The query looks like this:
A result could look like this:
I extended the
EntityFrameworkExecutionTests
as follows:This raises the following Exception:
This raises the following Exception:
I'm not really sure, whether my schema definition is wrong or i misunderstood the inline fragments/type condtions of graph-ql.
Do you have a suggestion or hint how to implement it correctly? Are type conditions already supported yet?
Thanks in advance :-)