3

While upgrading from Django 1.9.13 to Django 1.10.7 I encountered a weird issue with Django's native UUIDField.

We use this UUIDField on our custom User model like:

username = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)

In 1.9 this always returns a UUID instance. In 1.10 this returns a string when creating a new model instance.

Compare the following test examples:

1.9.13

>>> u = User.objects.last()
>>> u2 = UserFactory()
>>> u3 = User.objects.create()
>>> u.pk
UUID('e7e0f87d-1ed4-4293-829f-b0b745ccd676')
>>> u2.pk
UUID('f8e9a4a9-2265-4cd7-9813-00ffe7fd922a')
>>> u3.pk
UUID('0cb736d7-f8a0-4057-9c89-44fa114f4f82')

1.10.7

>>> u = User.objects.last()
>>> u2 = UserFactory()
>>> u3 = User.objects.create()
>>> u.pk
UUID('e7e0f87d-1ed4-4293-829f-b0b745ccd676')
>>> u2.pk
'f8e9a4a9-2265-4cd7-9813-00ffe7fd922a'
>>> u3.pk
'0cb736d7-f8a0-4057-9c89-44fa114f4f82'

This difference gives issues with various unittests. I can work around it by forcing both to string, but I wish to understand why UUIDField behaves the way it does as it feels inconsistent.

Michel Rugenbrink
  • 446
  • 6
  • 14
  • When creating `User`, In every case are you depending on default (`uuid.uuid4`)? OR sometimes you are giving it manually? – itzMEonTV Apr 24 '17 at 14:58
  • @itzmeontv The statements as listed under both 1.9.13 and 1.10.7 are exact. In both cases I use the UUIDFIeld default value which is uuid.uuid4 callable. – Michel Rugenbrink Apr 24 '17 at 15:01

1 Answers1

0

The problem was caused by changed behaviour in Django's AbstractBaseUser class. The class received a clean method which I called on save. Inside the new clean method a normalize_username method was called which forced the username to be text.

By avoiding the super call to AbstractBaseUser we no longer normalize the username which isn't something we wanted anyways as our username field is a UUID.

Michel Rugenbrink
  • 446
  • 6
  • 14