Okay fair enough, it wouldn't be much work to ship a PositiveBigAutoField
class.
On Wed, 7 Apr 2021 at 08:29, Florian Apolloner
wrote:
> On Tuesday, April 6, 2021 at 7:08:06 PM UTC+2 Adam Johnson wrote:
>
>> I also don't think this is necessary any more and can be closed.
>>
>>
>>> An explicit
On Tuesday, April 6, 2021 at 7:08:06 PM UTC+2 Adam Johnson wrote:
> I also don't think this is necessary any more and can be closed.
>
>
>> An explicit `id = PositiveBigIntegerField(...)` workaround would be fine
>> to be honest, for those that need it.
>
>
> I also would like to meet the djang
I also don't think this is necessary any more and can be closed.
> An explicit `id = PositiveBigIntegerField(...)` workaround would be fine
> to be honest, for those that need it.
I also would like to meet the django app that *does* need it (for non-silly
reasons like deciding to start ID's nea
I don't think we need this anymore, at least not by default. The default 64
bit range is probably enough for the time being. We could switch the
default to be `PositiveBigIntegerField` instead of `BigIntegerField` but
I'm not sure if that's sensible.
An explicit `id = PositiveBigIntegerField(...)`
Hi,
I think any primary key field which is an integer should be 64 bits
unsigned. 32 bits integers belong to the history, and there is no need for
negative primary keys. It's like when they defined IPv4, they defined it
with 32 bits and now we are stuck forever with 32 bits IP addresses. You
can n
Hello folks,
Now that we’ve completed these:
https://code.djangoproject.com/ticket/31007
https://code.djangoproject.com/ticket/30987
I’m wondering if https://code.djangoproject.com/ticket/56 is still something we
want to solve.
I feel like the workaround would be to explicitly define ``id =
m
I would like to try again:
I believe having a general setting for autofields could cause all
sorts of issues. As illustrated, I immediately thought that some
people might want to use that for migrating to UUID fields for that (I
read about using them somewhere about when I started using Django 5
ye
I believe that it is already possible to trigger new migrations in a
third-party app by changing its AppConfig.label, for example. Please correct me
if I’m wrong.
>From that perspective, it think it wouldn’t be wrong if a migration is created
>after someone changes its AppConfig’s default_auto_
Ah yes third party apps would be tricky.
An AppConfig setting would make sense, although I don't believe there's any
precedent. It could also be done by making DEFAULT_AUTOFIELD take a
dictionary mapping app labels to field names.
On Fri, 10 Apr 2020 at 08:29, Nick Pope wrote:
> Ah. I hadn't th
Ah. I hadn't thought about that - only got as far as being able to define a new
default value in DEFAULT_AUTOFIELD in the start project template so that
existing projects are not suddenly forced to migrate.
An alternative is to have something on the AppConfig. I'm sure for most people
the large
How would the strategy of having a setting generate new migrations work
with third-party apps? Generally migrations can't easily be added to them
by user projects and if more migrations are added to the third party app in
a later version, there will be an inconsistent history.
On Thursday, Apri
Having a DEFAULT_AUTOFIELD setting makes sense to me.
On Monday, April 6, 2020 at 12:48:10 PM UTC-4, Adam Johnson wrote:
>
> Jure - yes switching the setting should generate migrations for all
> affected models. The migration guide would cover changing models' primary
> key fields to PositiveBig
Jure - yes switching the setting should generate migrations for all
affected models. The migration guide would cover changing models' primary
key fields to PositiveBigAutoFields one at a time, perhaps with a mixin as
you've suggested. Maybe Django should provide such a mixin to ease the
migration.
Sorry if I understand stuff incorrectly, but:
I agree with Adam where he discusses migration issues, but I also don't
see how "DEFAULT_AUTOFIELD" setting could leave tables out of the
migration(s).
My understanding is that it would cause immediate re-provisioning of all
the pk fields, includ
I'm in favour of the move. The setting strategy seems appropriate.
Simon's comment on the PR that this affects a small % of projects is true.
But if your project does reach that scale, you're probably one of the
bigger Django organizations in the world - hopefully key advocates for the
framework.
Hi folks,
I’ve been working on ticket #56 "Primary key columns should be UNSIGNED"
(really old) for a while now. It’s cumbersome and hard to fix for some reasons,
including backwards compatibility, nothing that a single PR can solve but I’ll
try to summarize where things are at this moment. Ho
16 matches
Mail list logo
