Re: Default to BigAutoField

I agree with Tim. I also think the rename has potential to mess with historical migrations, or other uses of the field classes, since the output of deconstruct() will change the class name. On 31 August 2017 at 16:13, Tim Graham wrote: > Glancing at the PR, one thing I'm

Re: Default to BigAutoField

Glancing at the PR, one thing I'm not sure about is renaming AutoField to SmallAutoField. I think that's going to cause needless additional complexity and confusion among people who've worked with Django a long time. For example, you might think that "Small" there has a similar meaning as

Re: Default to BigAutoField

I don't think "primary key size" is something that's even within consideration for 99% of django apps. Sure a few more bytes are going to be wasted here, but you could argue the same that the default AutoField was already too big for most models that have 100's of instances and could use even a

Re: Default to BigAutoField

On Fri, Aug 18, 2017 at 5:43 AM, Markus Holtermann wrote: > > I'm don't fully agree with the approach. This essentially forces 3rd > party package authors to make the call about the primary key field size. > While for small to medium size projects BigAutoField is

Re: Default to BigAutoField

Thanks for taking the effort to work on this, Kenneth! I'm don't fully agree with the approach. This essentially forces 3rd party package authors to make the call about the primary key field size. While for small to medium size projects BigAutoField is unlikely required and only comes with

Re: Default to BigAutoField

To elaborate on the solution we eventually came up with - we default models to use a new BigAutoField that migrations will pick up on and generate migrations to alter columns to, but for safety reasons for those that don't read release notes, made the migration autodetector ask you if you want to

Re: Default to BigAutoField

On Friday 09 June 2017 15:59:50 Kenneth Reitz wrote: > 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. Existing models are the problem.

Re: Default to BigAutoField

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 bi

Re: Default to BigAutoField

On Saturday, 10 June 2017 10:33:35 UTC+1, Claude Paroz wrote: > > Another idea is to leverage the system check framework (--deploy part) to > warn when the max id is over 50% of available range. > I was about to suggest the same. Seems like something worth doing regardless of whether we change

Re: Default to BigAutoField

Le samedi 10 juin 2017 14:25:49 UTC+2, Curtis Maloney a écrit : > On 10/06/17 22:21, Claude Paroz wrote: > > Another idea would be to offer variants of models.Model which models > > could inherit from, like models.BigIntModel or models.UUIDModel. > > Ah, well... now you're talking. But then,

Re: Default to BigAutoField

On 10/06/17 22:21, Claude Paroz wrote: Le samedi 10 juin 2017 11:40:42 UTC+2, Curtis Maloney a écrit : Right, hence my point of having a global setting to say "the default auto-field is ..." I see, but this conforms to the pattern "use the same id field type for all models of my

Re: Default to BigAutoField

Le samedi 10 juin 2017 11:40:42 UTC+2, Curtis Maloney a écrit : > > Right, hence my point of having a global setting to say "the default > auto-field is ..." > > This would: > a) ... > I see, but this conforms to the pattern "use the same id field type for all models of my project". I'm not

Re: Default to BigAutoField

t; c) let 3rd party projects be agnostic > d) let people use UUIDField(default=uuid.uuid4) > e) possibly make it feasible to change mid-stream from AutoField to > BigAutoField... > > -- > C > > On 10/06/17 19:33, Claude Paroz wrote: > >> I think we should first discus

Re: Default to BigAutoField

c) let 3rd party projects be agnostic d) let people use UUIDField(default=uuid.uuid4) e) possibly make it feasible to change mid-stream from AutoField to BigAutoField... -- C On 10/06/17 19:33, Claude Paroz wrote: I think we should first discuss if it makes sense to set a BigAutoField by defau

Re: Default to BigAutoField

t feasible to change mid-stream from AutoField to BigAutoField... -- C On 10/06/17 19:33, Claude Paroz wrote: I think we should first discuss if it makes sense to set a BigAutoField by default for all tables. I'm not convinced of that yet. I looked at my projects with this perspective and found f

Re: Default to BigAutoField

I think we should first discuss if it makes sense to set a BigAutoField by default for all tables. I'm not convinced of that yet. I looked at my projects with this perspective and found for example a case where I have many small lookup tables (containing between 2-20 entries) for which I know

Re: Default to BigAutoField

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 >>>&

Re: Default to BigAutoField

onstraint 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 un

Re: Default to BigAutoField

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 h

Re: Default to BigAutoField

tively 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

Re: Default to BigAutoField

s 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

Re: Default to BigAutoField

alize 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 f

Re: Default to BigAutoField

e 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 applicati

Re: Default to BigAutoField

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 t

Re: Default to BigAutoField

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 t

Default to BigAutoField

, 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 d