in filter on DjangoFilterConnectionField works only for string

[tcleonard]

• What is the current behavior?
  When trying to use a __in filter in a DjangoFilterConnectionField it only works for strings because it tries to split the input.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem
  It's easy to reproduce in a unit test:

from graphene import ObjectType, Schema
from graphene.relay import Node
from graphene_django import DjangoObjectType
from graphene_django.tests.models import Pet

def test_in_filter():

    class PetNode(DjangoObjectType):
        class Meta:
            model = Pet
            interfaces = (Node,)
            filter_fields = {
                "name": ["exact", "in"],
                "age": ["exact", "in"],
            }

    class Query(ObjectType):
        pets = DjangoFilterConnectionField(PetNode)

    Pet.objects.create(name="Brutus", age=12)
    Pet.objects.create(name="Mimi", age=3)
    Pet.objects.create(name="Jojo, the rabbit", age=3)

    query = """
    query {
        pets (age_In: 3) {
            edges {
                node {
                    name
                    age
                }
            }
        }
    }
    """
    schema = Schema(query=Query)
    result = schema.execute(query)
    assert not result.errors

You can change the age_In: 3 input to whatever you can think of ("3", "3,", [3], ["3"]... ) nothing works.
For a string input you can do for example name_In: "Brutus,Mimi" and it will work but for example name_In: "Jojo, the rabbit" does not work because the comma in the name is interpreted as a delimiter.

• What is the expected behavior?
  Even for strings it should take a list of strings (instead of one string with the input separated by comma... because otherwise it forbids you to use comma in your string) and for other types it should take a list of object of that type.

[jrd]

Hi. While this correction is welcomed and I think it is better now, this breaks my code that was developed on version 2.13

So please, when you do this kind of API breakage (even if it was wrong in the first place), use a major release number bump. Or at least show a big WARNING when importing the lib or something.