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.
