Filtering using Django Integer Choices

[robertpro]

Hey guys, I am a real noob with GraphQL, but I think I found a bug, I am trying to filter using an integer choice, below you will see the definitions:

models.py

class Event(models.Model):
    KIND_XXX = 1
    KIND_CHOICES = (
        (KIND_XXX, "Dummy description"),
    )
    name = models.CharField(max_length=35)
    kind = models.IntegerField(choices=KIND_CHOICES)

schema.py

class EventNode(DjangoObjectType):
    class Meta:
        model = Event
        filter_fields = {
            'name': ['exact', 'in', 'icontains', 'istartswith'],
            'kind': ['exact', 'in', 'icontains', 'istartswith'],
        }
        interfaces = (graphene.relay.Node,)

class Query(graphene.ObjectType):
    event = graphene.relay.Node.Field(EventNode)
    all_events = DjangoFilterConnectionField(EventNode)

If I query using name, name__in, etc it works, but when I try to filter by kind__in it says I need an Float which is wrong.

Please note the Float there:

Result:

{
  "errors": [
    {
      "message": "Argument \"kind_In\" has invalid value \"1\".\nExpected type \"Float\", found \"1\".",
      "locations": [
        {
          "line": 2,
          "column": 22
        }
      ]
    }
  ]
}

As a second help request, I found other issue (but I am not sure if I am misunderstanding something) if I query for a not existent kind it returns the information:

Query for all records...

query{
  allEvents{
    edges{
      node{
        kind
        name
      }
    }
  }
}

Result for all records

{
  "data": {
    "allEvents": {
      "edges": [
        {
          "node": {
            "kind": "A_1",
            "name": "Event X"
          }
        }
      ]
    }
  }
}

Query for not existent kind choice

query{
  allEvents(kind: "2"){
    edges{
      node{
        kind
        name
      }
    }
  }
}

Result for not existent kind choice

{
  "data": {
    "allEvents": {
      "edges": [
        {
          "node": {
            "kind": "A_1",
            "name": "Event X"
          }
        }
      ]
    }
  }
}

I spent like 8 hours debugging, but I couldn't find any solution, if you can address for a solution, I can PR the fix (in case it is really a bug..,)

Thanks!

[zbyte64]

Try removing the quotes in kind_In: "1"

[robertpro]

@zbyte64 thank you for checking my issue, that does not work either :(

query{
  allEvents(kind_In: 1){
    edges{
      node{
        kind
        name
      }
    }
  }
}

Result:

{
  "errors": [
    {
      "message": "'float' object has no attribute 'split'",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "allEvents"
      ]
    }
  ],
  "data": {
    "allEvents": null
  }
}

This is the error on the console:

graphql.error.located_error.GraphQLLocatedError: 'float' object has no attribute 'split'

Which makes sense, it is really expecting a string, not a Float

For extra information, when I was debugging I realized that the exception was raised here, I have no idea how it went to BaseCSVWidget class

[zbyte64]

Ahh, then try: kind_In: [1]
It needs to be a list of numbers.

[robertpro]

Unfortunately that is not working either:

Result

"message": "Argument \"kind_In\" has invalid value [1].\nExpected type \"Float\", found [1]."

It still asking for a Float, which I think is the bug

[robertpro]

Same with other tries:
["1", "2"]
["1,2"]

[zbyte64]

Asking for a Float is definitely not right. Trying to find where that is specified atm. Another thing to try would be: [1. , 2.]

[zbyte64]

My best guess is that converter.convert_django_file_with_choices is not properly configuring the type in graphene. What is going on behind the scenes is that specifying a choices currently converts the field type to an Enum. Looking at our unit tests, we check for an Enum type but we do not validate the value subtype (I am not sure where that is accessed atm). We should start by writing a specific test (under tests.test_converter) with an IntegerField with choices.

[robertpro]

All tries were running without success:

[1., 2.] - Results in:

"Syntax Error GraphQL (2:25) Invalid number, expected digit but got: \",\".\n\n1: query{\n2:   allEvents(kind_In: [1., 2.]){\n                           ^\n3:     edges{\n"

[1.0, 2.0] - Results in:

"Argument \"kind_In\" has invalid value [1.0, 2.0].\nExpected type \"Float\", found [1.0, 2.0]."

[robertpro]

This is what I tried:

test_converter.py based on this test

def test_field_with_integer_choices_convert_enum():
    field = models.IntegerField(
        help_text="Status", choices=((1, "Active"), (2, "Inactive"))
    )

    class StatusModel(models.Model):
        status = field

        class Meta:
            app_label = "test"

    graphene_type = convert_django_field_with_choices(field)
    assert isinstance(graphene_type, graphene.Enum)  # pdb here (with Pycharm)

I couldn't find any place where the type/subtype were Float, under convert_django_field_with_choices.

So I tried to get the base class of the member without success, this is how I tried access:

graphene_type._meta.enum.__members__['A_1']
type(graphene_type._meta.enum.__members__['A_1'])  # Returns: EnumMeta

Attributes

from graphene.types.base import BaseType
from graphene.pyutils.init_subclass import InitSubclassMeta

isinstance(graphene_type._meta.enum.__members__['A_1'], BaseType)  # Returns False
isinstance(graphene_type._meta.enum.__members__['A_1'], InitSubclassMeta)  # Returns False

Unfortunately I don't have any other idea/knowledge to test, if you need any other information or idea I will try to help ASAP.

[zbyte64]

Looking at this closer after reading: https://docs.graphene-python.org/en/latest/types/enums/

I don't think we can have non-string based enum keys. You might be able to do: kind_In: ["A_1", "A_2"] as those are the generated enum keys.

This issue is probably a good example of why enums should be more opt-in.

[zbyte64]

My recommendation to work around would be to explicitly define kind at the EventNode without any enums as a plain integer field. It won't present choices but it would yield a more intuitive querying. Not sure how well that works with django filters though.

[changeling]

The second issue, returning all records as failure mode, may be related to this issue:

DjangoFilterConnectionField and filter_set issues.