Chad Kimes

Unfortunately the GraphQL spec doesn't have a great story for inheritance hierarchies that exist in OOP languages like C# and Java. The best way to achieve the above is to...

If GraphQL supported interfaces inheriting interfaces, we could get away with always just creating interfaces for base classes. There's no need to have a concrete object type if that type...

@MarianPalkus I like the idea of explicitly requiring the user to opt-in to inheritance. All of the solutions for inheritance are pretty gross to handle automatically, especially as you get...

Currently, args do not undergo any name transformation like properties do. There's not a particular reason for this, and I'm open to changing it. We do support input objects (https://facebook.github.io/graphql/#sec-Input-Values),...

I think adding deserialization to a Dictionary is a sensible thing to do. We've considered how to handle optional fields when deserializing to an object and it's a bit tricky,...

The rationale for using camel case was that the convention for GraphQL is to use camel-case names. Since the convention for C# properties is Pascal case, the `ToCamelCase` function just...

This is a pretty fun exception that I ran into a lot when building this library, particularly this little piece: ``` Message=Operation could destabilize the runtime. ``` This results from...

Hmm, that's problematic since I imagine that's forcing evaluation of the full query in SQL instead of doing something like a `SELECT TOP 1 ...` What was the exact exception...

Interesting... at first I thought it was the `transformed` variable that was for some reason not IQueryable, but I don't think that's right anymore. It should have failed the cast...

I'm digging through the NHibernate source to see where the issue might be. I have a few ideas, but I'll need to play around to make sure. However, I just...