As long as you changed the actual field that ended up under the "id"
column, then yes, migrations should detect it and apply all the changes
during an upgrade, including to foreign keys.
Generic foreign keys are another problem, however, not to mention the
prospect of how many migrations and ALTER TABLES this would result in on a
large project. We could include in the upgrade notes how to stave it off
(explicitly specify an ID field), but I'm sort of on the fence as to if
that's good enough.
Andrew
On Sat, Jun 10, 2017 at 9:53 AM, Collin Anderson <cmawebs...@gmail.com>
wrote:
> I might be wrong, but if the default changes, won't the migrations detect
> it and migrate it just fine, including foreign keys?
>
> All of my migrations have this:
> ('id', models.AutoField(auto_created=True, primary_key=True,
> serialize=False, verbose_name='ID')),
>
> So everyone would either need to manually specify the AutoField to keep
> the old behavior, or run makemigrations to auto-generate migrations to
> BigAutoField. This seems similar to increasing the max_length of
> EmailField, user.username, and user.last_name, though would affect a lot
> more models in this case.
>
> (I'm not sure what I think about the setting idea.)
>
> (While we're at it, maybe we could make it a (new) PositiveBigAutoField to
> help out the mysql folks and close the oldest open ticket:
> https://code.djangoproject.com/ticket/56 :)
>
>
>
> On Fri, Jun 9, 2017 at 9:37 PM, Tim Graham <timogra...@gmail.com> wrote:
>
>> I'm not sure how this could work with migrations. In a sense, it would
>> involve making the auto-generated primary key "swappable", including
>> foreign keys that point to it. This sounds like a headache.
>>
>> I haven't thought of a possible solution since Kenneth floated this idea
>> in #django-dev yesterday.
>>
>> On Friday, June 9, 2017 at 7:11:05 PM UTC-4, Curtis Maloney wrote:
>>>
>>> I know people hate settings, but what about one for auto id field type?
>>>
>>> It would let you handle backwards compatibility, uuid, and bigint...
>>>
>>> --
>>> C
>>>
>>>
>>> On 10 June 2017 5:42:42 AM AEST, Jacob Kaplan-Moss <ja...@jacobian.org>
>>> wrote:
>>>>
>>>> I think this would be a good improvement, and I'd like to see it. I've
>>>> been bitten by integers overflowing at least twice I can remember in my
>>>> career, which is two times too many.
>>>>
>>>> However, a major thing we'd have to work out is the upgrade path
>>>> Consider a simple model:
>>>>
>>>> class Person(Model):
>>>> name = CharField()
>>>>
>>>> In Django 1.11, this actually generates a model with an integer `id`
>>>> field. But in we change it, in Django vNext, that `id` field would "turn
>>>> into" a bigint magically without the underlying table changes. That'd be
>>>> confusing: you'd expect the model to be "fixed" by pugrading to vNext, but
>>>> it wouldn't be. I think the migrations engine would detect this as a
>>>> migration (?), so perhaps that's the path forward, but it could still be
>>>> super-confusing. We've never shipped a release of Django that required a
>>>> migration to _all_ your models.
>>>>
>>>> Have you thought about what the upgrade path should look like, Kenneth?
>>>>
>>>> Jacob
>>>>
>>>> On Fri, Jun 9, 2017 at 11:24 AM, Kenneth Reitz <ken...@heroku.com>
>>>> wrote:
>>>>
>>>>> Dear Django Dev,
>>>>>
>>>>>
>>>>>
>>>>> At Heroku, we have the privilege of seeing an extremely broad range of
>>>>> customers utilizing tools like Django to build their applications and
>>>>> companies. One of the things that we’ve seen customers hit, time and time
>>>>> again when using tools like Django, is integer overflows for primary keys.
>>>>> Their application starts behaving unpredictably once they reach the
>>>>> overflow, not even knowing such a constraint exists, and they often think
>>>>> the problem is with their database provider, rather than with their
>>>>> schema.
>>>>> Once they realize what is wrong, it’s a relatively trivial fix, but a
>>>>> migration can take several hours to complete, which results in
>>>>> unacceptable
>>>>> amounts of downtime.
>>>>>
>>>>>
>>>>>
>>>>> Because of this, Heroku, as a company, would like to encourage bigints
>>>>> as a sane reasonable default for primary keys for application models. If
>>>>> the Django project agrees with this idea, that would mean that Django
>>>>> would
>>>>> provide BigAutoField as the default for ‘id’ instead of AutoField.
>>>>>
>>>>>
>>>>>
>>>>> Rails made this change recently
>>>>> <http://www.mccartie.com/2016/12/05/rails-5.1.html>, and has seen
>>>>> success in doing so.
>>>>>
>>>>>
>>>>>
>>>>> I’m happy to provide the code to do this, but I wanted to discuss it
>>>>> here before doing so, to hear what the general consensus was to the
>>>>> proposal of such a change.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Pros:
>>>>>
>>>>> -
>>>>>
>>>>> Users of Django, following the docs, won’t accidentally hit the
>>>>> int overflow barrier.
>>>>> -
>>>>>
>>>>> Encourages best-practices from the beginning.
>>>>> -
>>>>>
>>>>> Bigints don’t take up much more storage than ints when using
>>>>> Postgres.
>>>>> -
>>>>>
>>>>> In-line with other frameworks moving forward on this issue, like
>>>>> Rails <http://www.mccartie.com/2016/12/05/rails-5.1.html>.
>>>>>
>>>>>
>>>>>
>>>>> Cons:
>>>>>
>>>>> -
>>>>>
>>>>> Backwards compatibility would need to be considered.
>>>>>
>>>>>
>>>>> Why not UUID?
>>>>>
>>>>>
>>>>>
>>>>> I agree! I love using UUID for my primary keys, and I think a patch to
>>>>> Django which provides an AutoUUIDField would be wonderful. However, there
>>>>> are a few major drawbacks to making this the new default:
>>>>>
>>>>>
>>>>>
>>>>> 1.
>>>>>
>>>>> It’s confusing to new users, would make onboarding process more
>>>>> difficult.
>>>>> 2.
>>>>>
>>>>> UUID is difficult to implement in MySQL.
>>>>> 3.
>>>>>
>>>>> UUID has larger storage requirements.
>>>>> 4.
>>>>>
>>>>> Incrementing IDs are actually useful.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> So, my proposal is to simply lift the int barrier to a bigint barrier
>>>>> for new Django applications, and I think it will save a lot of developers
>>>>> a
>>>>> lot of pain in the long run.
>>>>>
>>>>>
>>>>>
>>>>> Many thanks,
>>>>>
>>>>>
>>>>>
>>>>> Kenneth Reitz
>>>>>
>>>>> Heroku Python
>>>>>
>>>>> --
>>>>> 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 https://groups.google.com/group/django-developers.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/django-developers/6fe3401c
>>>>> -4404-4bd8-9d22-58df95cd1348%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/django-developers/6fe3401c-4404-4bd8-9d22-58df95cd1348%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>> --
>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>>
>> --
>> 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 post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/3753d789-264b-4771-9949-06283ee5c6f2%
>> 40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/3753d789-264b-4771-9949-06283ee5c6f2%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> 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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CAFO84S6BL3XD2KZjHa99q0tuELkGg
> bZHqnv-2qBpDjvog6jH8A%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAFO84S6BL3XD2KZjHa99q0tuELkGgbZHqnv-2qBpDjvog6jH8A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAFwN1upLQfsf7y1ajEp2tARooELASCmDoxkErdU0SL9w6cQmgQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
