@tambeta : Thanks for addressing this.

It seems impossible to support GenericReferenceField after investigation ... Orz -- it's too dynamic that I don't know how to convert it to fit graphql's model,

And even there is a way to do it, could you image how to write graphql query?

Any thought? @zrlay

It seems to me like GenericReferenceField with choices naturally maps to graphene.Union and would be queried via GraphQL using inline fragments. I'm not sure if a Union subclass could be constructed automatically by graphene-mongo or should be passed in - possibly both options might be supported.

A GRF without choices is a schemaless structure and thus clashes with GraphQL philosophy of a full static schema. Indeed I cannot see this case being supported.

This was my thought as well; as long as the set of choices is provided in the GenericReferenceField, and those choices each are found in the same registry, we should be able construct a Union that has Dynamic types.

Eventually I'd like to see generated interfaces from MongoEngine classes that are parents of multiple children found in the registry, too.

Hi @abawchen,
Thanks for helping with the support of GenericReferenceField, it is working fine with the code from the branch feat-generic-reference-field.

It would be great to have support for the field type ListField(GenericReferenceField()), looking forward to hear the possibilities from you.

@tambeta @zrlay : Thanks for you input, and it supports GenericReferenceField on updated master or 0.2.3. Please give it a try and feedback if any issues.

@arunsureshkumar : Will take care it later :)