Add automatic type generation for Django models

[jaydenwindle]

This PR adds automatic GraphQL type generation for Django models.

Usage:

# models.py
from django.db import models

class Todo(models.Model):
    name = models.CharField(max_length=250)
    done = models.BooleanField(default=False)

# types.py
from todo.models import Todo
from strawberry.contrib.django.type import model_type

@model_type(model=Todo, fields=['id', 'name', 'done'])
class TodoType:
    pass

# OR

@model_type
class TodoType:
    class Meta:
        model = Todo
        fields = ['id', 'name', 'done']

# Generated type:
type TodoType {
    id: ID!
    name: String!
    done: Boolean!
}

[codecov]

Codecov Report

Merging #137 into master will decrease coverage by 0.6%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #137      +/-   ##
==========================================
- Coverage   90.65%   90.04%   -0.61%     
==========================================
  Files          23       22       -1     
  Lines         492      432      -60     
==========================================
- Hits          446      389      -57     
+ Misses         46       43       -3

[patrick91]

Awesome! I'm going to take a look at this pretty soon, thank you so much for this!

I think we might have to spend a bit of time on choices, which seems to be a pain point in graphene (but this can be done, and probably should, in another PR)

[botberry]

Thanks for adding the RELEASE.md file!

Here's a preview of the changelog:

---

Added automatic GraphQL type generation for Django models.

Usage:

# models.py
from django.db import models

class Todo(models.Model):
    name = models.CharField(max_length=250)
    done = models.BooleanField(default=False)

# types.py
from todo.models import Todo
from strawberry.contrib.django.type import model_type

@model_type(model=Todo, fields=['id', 'name', 'done'])
class TodoType:
    pass

# OR

@model_type
class TodoType:
    class Meta:
        model = Todo
        fields = ['id', 'name', 'done']

# Generated type:
type TodoType {
    id: ID!
    name: String!
    done: Boolean!
}

[jaydenwindle]

@patrick91 No worries! Happy to contribute :)

Can you expand a little on what needs to be done as far as choices are concerned?

[patrick91]

@jaydenwindle I think it might be useful to convert django choices to enums, but we need to investigate this a bit more (might not be worth the troubles)

See also: graphql-python/graphene-django#185 (comment)

[jaydenwindle]

@patrick91 Got it, that makes sense.

Auto conversion to enums would definitely be useful. I'll log an issue for adding choices support and we can brainstorm there.

[patrick91]

do we need to test this with async?

[jaydenwindle]

I believe so, since it uses async/await. Otherwise pytest skips it.

[patrick91]

we have graphql sync we can use ;) https://github.com/strawberry-graphql/strawberry/blob/master/tests/test_schema.py#L9

[lostb1t]

Would be great to see this merged. Whats needed to push this forward? Anything I can do to help?

[patrick91]

@sarendsen hey there! we are currently focusing on making strawberry a bit more stable, so we parked this for a bit.

The last time I was thinking about this I wasn't sure about the API.

# models.py
from django.db import models

class Todo(models.Model):
    name = models.CharField(max_length=250)
    done = models.BooleanField(default=False)

# types.py
from todo.models import Todo
from strawberry.contrib.django.type import model_type

@model_type(model=Todo, fields=['id', 'name', 'done'])
class TodoType:
    pass

This looks inline with what strawberry does, but I think we need to find a way to handle additional fields, ie:

@model_type(model=Todo, fields=['id', 'name', 'done'])
class TodoType:
    name: str # what happens here? is this name coming from the instance?

    @strawberry.field
    def example(self, info) -> str:
        return self.name.upper() # <--- what about this? does it make sense to
                                 # have self as the current instance?
                                 # maybe we can use self.instance.name instead

And then there's also to talk about providing data for editing/querying data.

Would like to discuss these? We have a discord channel, I think it might be easier to chat/talk there :) https://discord.gg/3uQ2PaY

[Rocamonde]

Hi guys, just posed asking about this on another issue but found this one later. I see that there is already some work on adding support for Django models. I'd like to contribute to this. Do you think you can bring me up to speed? Does this support QuerySets?

I think this is not in the Docs, as before coming here I did not find anything. I think a lot of docs are also missing in general. Happy to contribute writing docs too.

Let me know how I can be helpful,

Best

[patrick91]

@Rocamonde we put this on hold for the time being, as we are finishing up working on strawberry and getting it stable first. I saw you joined the discord channel, maybe we can discuss the next steps there. I'm finishing this PR #352, it should unblock this :)

[patrick91]

I'll close this for now, we have a discusson on pydantic here: #444

That will probably shape how we handle the django integration too in future :)