I don't think we need this anymore, at least not by default. The default 64 bit range is probably enough for the time being. We could switch the default to be `PositiveBigIntegerField` instead of `BigIntegerField` but I'm not sure if that's sensible.
An explicit `id = PositiveBigIntegerField(...)` workaround would be fine to be honest, for those that need it. On Tue, Apr 6, 2021 at 1: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/CAFNZOJMrob2w9qtp2ohHmQSqh%3DzqSAaBbJ1TzXmTPzJfuP4TvA%40mail.gmail.com.
