I have detected a regression where the built in create mutation is not able to properly process the input and create a django model with a foreign key relation. Consider the example:

class Booking(Model):
    boat_id: uuid.UUID
    boat = ForeignKey(Boat, on_delete=django_models.CASCADE)


@strawberry_django.input(floatist_models.Booking)
class CreateBookingInput:
    boat: uuid.UUID

This used to work in the past but has been broken with 170c27c. Django now returns ValueError: Cannot assign "UUID('dafceb8a-2f28-4be8-b73a-b196a77126f4')": "Booking.boat" must be a "Boat" instance.

The input is not processed before calling the manager create method. The input is correctly processed when creating the dummy instance for form cleaning OR when using the built in update mutation. The update and create mutations have diverged significantly and cause unexpected behavior. And btw, the argument that the manager create method must be used can be extended to manager update method as well, so that's another inconsistency that has been introduced.

For the time being, I can work around the problem by annotating the input with strawberry.ID instead of uuid.UUID. But that's not good overall as I now have discrepancy between typing in my create vs update mutations, I lose the strong UUID typing in the schema and validation (so it will also accept an int or any string for that matter) and I have to deal with a string instead of a proper UUID object instance.