Description
class User(DjangoObjectType):
class Meta:
model = get_user_model()
only_fields = ['signup_site_version']
class Query(graphene.ObjectType):
user = graphene.Field(User)
def resolve_user(self, args, context, info):
return user_from_info(info) # return django user from contextUser model:
@python_2_unicode_compatible
class User(AbstractUser):
(...)
signup_site_version_choices = [(1, u'site 1'), (2, u'site 2')]
signup_site_version = models.IntegerField(choices=signup_site_version_choices)Query
query {
user {
signupSiteVersion
}
}
Result
{
"data": {
"user": {
"signupSiteVersion": "A_1"
}
}
}
A copy-paste from where the weird value is born:
def convert_choice_name(name):
name = to_const(force_text(name))
try:
assert_valid_name(name)
except AssertionError:
name = "A_%s" % name
return nameWe've had similar problems in the old graphene (< 1.0): graphql-python/graphene#134
The output is "A_1", because the field converter assumes django choices are tuples (id, name) where name is a constant name (not containing spaces etc.) or is convertible to a valid constant name. For some reason it is not successful while doing that for "site 1", but that is not an issue. The problem is it assumes we would like to do that.
In our django application (I suppose it is the norm) we use the second tuple element as a human-readable label. It means that in most cases replacing space with an underscore will do the work, but
in the other names are still bound to be long and there is no character we can safely assume the name won't contain (including hyphens, all native character varieties etc.).
The Enum fields are certainly nice, as their values are schema-validated, to say the least, but I doubt automatic conversion should be the only possible behaviour.