Re: Defaulting to use BigAutoField in models

ind out at the worst possible time - out >>> of the blue at night and during a period of rapid growth. The process for >>> fixing this issue also becomes a lot harder as your data grows - when >>> you’ve hit the limit you’re looking at a multi-hour `ALTER TABLE` on >>

Re: Defaulting to use BigAutoField in models

a lot harder as your data grows - when >> you’ve hit the limit you’re looking at a multi-hour `ALTER TABLE` on >> Postgres during which writes and reads are blocked, or a risky operation to >> create a new table with the correct primary key and copy old data over in >>

Re: Defaulting to use BigAutoField in models

n >> you’ve hit the limit you’re looking at a multi-hour `ALTER TABLE` on >> Postgres during which writes and reads are blocked, or a risky operation to >> create a new table with the correct primary key and copy old data over in >> batches. Basically if you’ve experience

Re: Defaulting to use BigAutoField in models

operation to > create a new table with the correct primary key and copy old data over in > batches. Basically if you’ve experienced this before you wouldn’t wish it > on your worst enemy. > > I’m proposing that we add a `MODELS_PRIMARY_KEY` (name improvements > welcome!) s

Re: Defaulting to use BigAutoField in models

ate every AutoField to BigAutoField without the > need to specify them manually. > > > -- > Caio > > > > On 18 Jun 2020, at 09:40, Adam Johnson wrote: > > Would we be able to provide instructions on how to migrate from SIGNED INT >> to UNSIGNED BIG INT? Pe

Re: Defaulting to use BigAutoField in models

What about third party apps? It would be great to migrate every AutoField to BigAutoField without the need to specify them manually. -- Caio > On 18 Jun 2020, at 09:40, Adam Johnson wrote: > > Would we be able to provide instructions on how to migrate from SIGNED INT to >

Re: Defaulting to use BigAutoField in models

> > Would we be able to provide instructions on how to migrate from SIGNED INT > to UNSIGNED BIG INT? Perhaps a management command that outputs SQL like > sqlmigrate? > It would only be needed to add this to the model: id = BigAutoField() Then migrations would pick it up, because

Re: Defaulting to use BigAutoField in models

> On 17 Jun 2020, at 16:56, Adam Johnson wrote: > > I think special casing the migrations framework is an avenue to explore, so I > created this today and to my surprise it seems to work quite well: > https://github.com/orf/django/commit/0a335f208cee1376c25eff55c6f866de122c7839 >

Re: Defaulting to use BigAutoField in models

sn’t distinguish between 32/64 bit numbers so code will > continue to work as-is. > - Third party migrations that ship with 32 bit columns won’t be impacted, > and it’s up to them to create migrations if they want to. > - Adding `id = BigAutoField(primary_key=True)` to a model will cr

Re: Defaulting to use BigAutoField in models

hem to create migrations if they want to. - Adding `id = BigAutoField(primary_key=True)` to a model will create an explicit AlterField migration, when projects are able to migrate. Am I missing something? > I haven't thought this through, but maybe it's possible to restrict the > chan

Re: Defaulting to use BigAutoField in models

type. For those who want to fixed field sizes, BigAutoField and SmallAutoField could be left, and MediumAutoField added. (Whilst poking around I think I spotted a small cleanup: https://code.djangoproject.com/ticket/31698 ) On Fri, 12 Jun 2020 at 11:40, Tom Forbes wrote: > I think we should

Re: Defaulting to use BigAutoField in models

’s a really good point, I got a bit swept up with the idea to realise that it would break a lot of things if applied generally! > The autodetector knows if a model is new. It could be that during one version > Django outputs BigAutoField for fields added in CreateModel only. We could make

Re: Defaulting to use BigAutoField in models

Big +1 on solving this from me. - The setting would take any dotted path to a class, or a single class name > for a build in field. This would potentially solve [3], and could be useful > to people who want to default to other fields like UUIDs (or a custom > BigAutoField) for whatev

Re: Defaulting to use BigAutoField in models

For the record, there was a related discussion a few months ago: https://groups.google.com/d/msg/django-developers/VFXZpHnuEJc/bbefjX9yCQAJ > On 11 Jun 2020, at 12:28, Tom Forbes wrote: > > nsures it will be used meaningfully and not forgotten about until it’s too > late. > -- You received

Defaulting to use BigAutoField in models

wouldn’t wish it on your worst enemy. I’m proposing that we add a `MODELS_PRIMARY_KEY` (name improvements welcome!) setting that _defaults_ to `BigAutoField`, with prominent docs/release notes saying that to preserve the existing behaviour this should be set to `AutoField`. I think this the only

Re: Default to BigAutoField

y 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

Re: Default to BigAutoField

s and could use > even a one byte primary key. > > Defaulting to BigAutoField everywhere is the simple solution that stops > everyone from ever worrying about their tables filling up. Additionally > using compressed tables helps reclaim nearly all those unused bytes, at > least on My

Re: Default to BigAutoField

nces and could use even a one byte primary key. Defaulting to BigAutoField everywhere is the simple solution that stops everyone from ever worrying about their tables filling up. Additionally using compressed tables helps reclaim nearly all those unused bytes, at least on MySQL. On 18 August 201

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 unlike

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

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 wa

Re: Default to BigAutoField

I have opened a pull request: https://github.com/django/django/pull/8924 Andrew and I came up with a good solution for migrations, together at DjangoCon. On Wednesday, June 14, 2017 at 7:36:36 AM UTC-7, Melvyn Sopacua wrote: > > On Friday 09 June 2017 15:59:50 Kenneth Reitz wrote: > > > Howeve

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. Then

Re: Default to BigAutoField

I really like this idea. We created a custom BigAutoField for our systems with sharded databases, and fast growing data. I understand the desire to fix it for new projects moving forward, but this smells a little like what happened with custom User models - it was introduced for new projects

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 t

Re: Default to BigAutoField

#x27;re talking. But then, you can do this already as an > abstract base with TYPE as id... > > class BigIntModel(models.Model): > id = BigAutoField(primary_key=True) > class Meta: > abstract = True > Absolutely! It would only be a convenience thing.

Re: Default to BigAutoField

h, well... now you're talking. But then, you can do this already as an abstract base with TYPE as id... class BigIntModel(models.Model): id = BigAutoField(primary_key=True) class Meta: abstract = True -- C -- You received this message because you are subscribed

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 su

Re: Default to BigAutoField

they want... On 10/06/17 19:40, Curtis Maloney wrote: > Right, hence my point of having a global setting to say "the default > auto-field is ..." > > This would: > a) let people continue to use AutoField > b) let people opt for BigAutoField > c) let 3rd party pro

Re: Default to BigAutoField

f) let MySQL users opt for PositiveBigAutoField if they want... On 10/06/17 19:40, Curtis Maloney wrote: Right, hence my point of having a global setting to say "the default auto-field is ..." This would: a) let people continue to use AutoField b) let people opt for BigAutoField

Re: Default to BigAutoField

Right, hence my point of having a global setting to say "the default auto-field is ..." This would: a) let people continue to use AutoField b) let people opt for BigAutoField c) let 3rd party projects be agnostic d) let people use UUIDField(default=uuid.uuid4) e) possibly make it 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

Re: Default to BigAutoField

7;)), > > 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 aff

Re: Default to BigAutoField

yone 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. (

Re: Default to BigAutoField

at 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 exi

Re: Default to BigAutoField

elatively 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 reaso

Re: Default to BigAutoField

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 defaul

Re: Default to BigAutoField

s 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

Re: Default to BigAutoField

ial 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 > Djan

Re: Default to BigAutoField

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

Re: Default to BigAutoField

t; 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

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

Re: BigAutoField

On 23 tammi, 16:09, SteveB wrote: > Hi, > Can anybody provide an update on the request to define a BigAutoField in > Django? > We could really use this model field type without having to do workarounds > and customizations. > Can any of the Django developers comment on when thi

Re: BigAutoField

com/en/dev/internals/contributing/ Good luck! Wim On Wednesday, 23 January 2013 15:09:29 UTC+1, SteveB wrote: > > Hi, > Can anybody provide an update on the request to define a BigAutoField in > Django? > We could really use this model field type without having to do workarounds &g

BigAutoField

Hi, Can anybody provide an update on the request to define a BigAutoField in Django? We could really use this model field type without having to do workarounds and customizations. Can any of the Django developers comment on when this will be released? Thanks, Steve -- You received this