Add support for unsigned primary keys in MySQL

[Markus Amalthea Magnuson]

I've picked up this old ticket:

https://code.djangoproject.com/ticket/56

After some initial discussions on #django-dev it seems like wontfixing it would be an option too, so I wanted to ask about core devs' view on this:

Is implementing opt-in support for unsigned primary keys on MySQL still interesting?

[Loïc Bistuer]

I think we can link https://code.djangoproject.com/ticket/56 to https://code.djangoproject.com/ticket/14286.

The problem is not so much how to create an UnsignedAutoField or a BigAutoField which is rather trivial, but how to deal with foreign keys pointing to them and how to migrate them. As far as I know it's the only case where changing one field requires migrations in multiple apps, and since you don't necessarily have the source repo available for them, it's not clear how we can handle it.

There is also a design issue, do we want AutoField + UnsignedAutoField + BigAutoField + UnsignedBigAutoField and their ForeignKey counterparts? That's ugly IMO. We could have AutoField(storage=models.IntegerField) which is slightly better, or we could wait to have nailed the Virtual/Composite API and AutoField would become virtual and use the same API as composite fields to pick its backing field (e.g. id = BigIntegerFIeld(); pk = AutoField(concrete='id')).

All in all, I'm not for a wontfix, but as with any low digits tickets a proper fix is far from easy.

--
Loïc

> --
> You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAOXH8SX2gdM3OSDYkY7W94MVac%2Bh9Wo68r2qaRzisbEiYOzhoA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Andrew Godwin]

I agree with Loïc that this problem is probably best solved when the virtual/composite stuff is finally sorted out; I don't want us to put in a quicker fix that's not going to match those, and that's already going to have to deal with things like composite keys and potentially changing FKs anyway.

As for the migration end, we can handle it somehow. My first thought would be to compare FK types from the migration and from the models in the migration autodetector and emit changes there if needed, as two or three parts (separate out dropping the FK constraint separately, and make it run before the main PK change).

Andrew

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/76CE4389-DE36-4FBA-9E49-02ED5AFAFF9D%40gmail.com.