Re: Default to BigAutoField

2017-06-09 Thread Tim Graham
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

Re: Default to BigAutoField

2017-06-09 Thread Curtis Maloney
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 wrote: >I think this would be a good improvement, and I'd like to see it.

Re: Default to BigAutoField

2017-06-09 Thread Curtis Maloney
I don't see it helping once you hit the problem, but like custom user its a recommendable setting for pre planning -- C On 10 June 2017 11:37:04 AM AEST, Tim Graham wrote: >I'm not sure how this could work with migrations. In a sense, it would >involve making the

Re: Default to BigAutoField

2017-06-09 Thread Collin Anderson
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

Re: Allow extra blank rows for adding new records when using list_editable in admin change list view.

2017-06-09 Thread John-Paul Jorissen
I would love to see this change implemented as well. I have a few models that would benefit from having a quick entryline at the bottom of the list_display. Personally, I think that the first possibility, where only the items that are in the 'list_editable' tuple would be editable in the

Re: On ASGI...

2017-06-09 Thread Tom Christie
Figure I may as well show the sort of thing I'm thinking wrt. a more constrained consumer callable interface... * A callable, taking two arguments, 'message' & 'channels' * Message being JSON-serializable python primitives. * Channels being a dictionary of str:channel * Channel instances expose

Default to BigAutoField

2017-06-09 Thread Kenneth Reitz
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

Re: Default to BigAutoField

2017-06-09 Thread Jacob Kaplan-Moss
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):

Re: Default to BigAutoField

2017-06-09 Thread Tom Forbes
How would this work with generic foreign keys as well? Those migrations couldn't be automatic. On 9 Jun 2017 20:43, "Jacob Kaplan-Moss" 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

Re: Default to BigAutoField

2017-06-09 Thread Kenneth Reitz
My initial thought was to just have this apply to *new* Django applications, if that's possible. Running this migration could take quite some time on some larger apps, and would require a non-trivial amount of time to execute. -- Kenneth Reitz > On Jun 9, 2017, at 3:53 PM, Tom Forbes

Re: Default to BigAutoField

2017-06-09 Thread Kenneth Reitz
However, it should also be noted that those same larger applications are the ones that are likely to run into this problem eventually, so perhaps forcing the migration is the best path moving forward. Interested in hearing thoughts about this. -- Kenneth Reitz > On Jun 9, 2017, at 3:54 PM,