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
>>> Postgres during which writes and reads are blocked, or a risky operation to
>>> crea
oking 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 experienced this before you wouldn’t wish it
>> on y
;> 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 experienced this before you wouldn’t wish it
>> on your worst enemy.
>>
>>
d 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!) setting that _defaults_ to `BigAutoField`, with prominent
> do
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
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
>
>
> 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, be
> 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
>
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 create an
> explicit Alt
o them 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
> change to insi
.
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 restr
y 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 every a
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
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
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
hink "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 co
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 2
d 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 2017 at 17:14, And
On Fri, Aug 18, 2017 at 5:43 AM, Markus Holtermann <i...@markusholtermann.eu
> 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 pro
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
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
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.
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
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
.. 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
>
Absolutely! It would only be a convenience thing. The
Ah, 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 to the Goo
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
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
&g
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
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 i
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
>
> 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
&
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
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
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
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
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
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
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
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
, 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
On 23 tammi, 16:09, SteveB <smbroo...@gmail.com> 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 de
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
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
44 matches
Mail list logo
