Hi, I think any primary key field which is an integer should be 64 bits unsigned. 32 bits integers belong to the history, and there is no need for negative primary keys. It's like when they defined IPv4, they defined it with 32 bits and now we are stuck forever with 32 bits IP addresses. You can never know when a model will require more than 2**31 records and I don't see any use in using 32 bits in 2021.
By the way, if we use 64 bits - it doesn't matter that much if the integer is signed or unsigned - I don't think we need the 64th bit anyway. Uri. אורי u...@speedy.net On Tue, Apr 6, 2021 at 3:12 PM Caio Ariede <caio.ari...@gmail.com> wrote: > Hello folks, > > Now that we’ve completed these: > > https://code.djangoproject.com/ticket/31007 > https://code.djangoproject.com/ticket/30987 > > I’m wondering if https://code.djangoproject.com/ticket/56 is still > something we want to solve. > > I feel like the workaround would be to explicitly define ``id = > models.PositiveBigIntegerField(primary_key=True)`` > > In the other hand, we could also add ``PositiveBigAutoField`` to make > things easier now that we have the ability to define the > ``default_auto_field`` per app. > > Thoughts? > > — Caio > On 12 Apr 2020 15:01 -0300, Jure Erznožnik <jure.erznoz...@gmail.com>, > wrote: > > I would like to try again: > I believe having a general setting for autofields could cause all > sorts of issues. As illustrated, I immediately thought that some > people might want to use that for migrating to UUID fields for that (I > read about using them somewhere about when I started using Django 5 > years ago). The point is that an option like that immediately sparks > imagination. > > However, the problem being attempted at here is only migrating from > signed to unsigned integer. A very minor change most deployments would > not even be affected by. > > That one could be handled less aggressively by: > > OTOH, JUST FOR the unsigned vs signed integer PK, it should be relatively > easy to modify makemigrations code detect existing migrations for the > model, detect that the only difference is IntegerField vs > PositiveIntegerField and in this case skip generating the migration (for > migrating the field to an unsigned one). There could also be a flag to the > management command specifying to force generating said migrations. > > > I believe this would be unintrusive enough allowing everyone to > migrate their models at will. Since most of users won't even notice > the difference, a solution like this could be preferable even if it > introduces one additional special case in the code. > OTOH, the proposed setting DOES provide more flexibility (to introduce > more varied options for the PK field), but a necessity for a > biginteger or guid or anything else, for that matter, is already > catered for in the API - by specifying the super-special pk manually > for the affected table. > > I sure hope I'm not just derailing the discussion with my uninformed > ideas, but perhaps the minor change could be handled in a simpler > manner like proposed above. > > LP, > Jure > > On Sat, Apr 11, 2020 at 12:21 AM Caio Ariede <caio.ari...@gmail.com> > wrote: > > > I believe that it is already possible to trigger new migrations in a > third-party app by changing its AppConfig.label, for example. Please > correct me if I’m wrong. > > From that perspective, it think it wouldn’t be wrong if a migration is > created after someone changes its AppConfig’s default_auto_field. The extra > migrations could be handled manually using MIGRATION_MODULES. > > I feel like adding such option to AppConfig would give a pretty good > flexibility, but I’m not sure it dismisses the use of > settings.DEFAULT_AUTO_FIELD. Specially if one desires to keep an old > default behavior. > > -- > Caio > > > > On Apr 10, 2020, at 04:29, Nick Pope <nickpope1...@gmail.com> wrote: > > People can also choose to set this for a third-party app by subclassing > the AppConfig, but as you say, they'd then be forced to handle migrations > manually - is this even avoidable? I'm not sure how this would look for > moving to a new default though. > > > -- > 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-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/3FE8A93E-1A7F-436D-87CC-3D87A6C16801%40gmail.com > . > > > -- > 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-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAJ%3D9zicjm4nWYRD9FM0EcMVFbWtj8wPHB084P%2BC_5x9wLgrgPQ%40mail.gmail.com > . > > -- > 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-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/7c2f1424-4d48-40eb-832a-d7bbe492d0c5%40Spark > <https://groups.google.com/d/msgid/django-developers/7c2f1424-4d48-40eb-832a-d7bbe492d0c5%40Spark?utm_medium=email&utm_source=footer> > . > -- 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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeEX%2BhAqa75z-%2BsU8YjrojgFCROc%2B8un5yC_vuOAQJDmkA%40mail.gmail.com.
