Django default PK type setting

[Emett Speer]

Hello Everyone,

I would like to propose the exploration of adding a default PK setting do Django. This could be a flag at project creation time or a setting to be set before the first migration takes place.

This would allow the developer to set the default PK in Django to something like UUID. With this things like the default Group, User, etc.. models would have UUID based PK's rather then Int based ones and all future tables would have UUID PK's by default.

Please let me know what you think.

[Tim Graham]

Sounds quite complicated. In particular, how could we reasonably test that contrib apps work with arbitrary PKs?

[Emett Speer]

I agree that it will be complicated, hard, and time consuming problem to solve but I would like to explore what it would take to attempt and if it would even be possible.

We could start with standard PK substitutes such as UUID's and then expand from there as needed.

[Ares Ou]

You could just explicitly claim the 'id' field in your model, assign a desired type.

If you want a model that has the default primary key as UUID for future use, you could write a customized class inherited from models.Model, overriding the 'id' field.

I don't feel like this is something needed to be integrated into the official code.

See Automation Primary Key Fields: https://docs.djangoproject.com/en/1.10/topics/db/models/#automatic-primary-key-fields

Best regards,

Ares Ou

Software Engineer / Full-Stack Python Developer  |  Phone: (510) 328 - 5968

Blog: http://aresou.net  |  Github: https://github.com/aresowj  |  Stack Overflow: http://stackoverflow.com/users/5183727/ares-ou

Ares Ou

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/01763b34-8970-47a4-950e-04343e717514%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Emett Speer]

My suggestion is more to keep a standard PK for the project rather then having 2 PK's. One for the default Django models and one for the rest of your project.

With the current setup you would need to override the base User model to change the PK from an int to what the rest of the project is using. Where if you could set the default PK for the project it would always be of the same type unless otherwise declared.

On Tuesday, August 30, 2016 at 1:20:28 PM UTC-7, Ares Ou wrote:

You could just explicitly claim the 'id' field in your model, assign a desired type.

If you want a model that has the default primary key as UUID for future use, you could write a customized class inherited from models.Model, overriding the 'id' field.

I don't feel like this is something needed to be integrated into the official code.

See Automation Primary Key Fields: https://docs.djangoproject.com/en/1.10/topics/db/models/#automatic-primary-key-fields

Best regards,

Ares Ou

Software Engineer / Full-Stack Python Developer  |  Phone: (510) 328 - 5968

Blog: http://aresou.net  |  Github: https://github.com/aresowj  |  Stack Overflow: http://stackoverflow.com/users/5183727/ares-ou

Ares Ou

On Tue, Aug 30, 2016 at 11:43 AM, Tim Graham <timog...@gmail.com> wrote:

Sounds quite complicated. In particular, how could we reasonably test that contrib apps work with arbitrary PKs?

On Tuesday, August 30, 2016 at 2:32:18 PM UTC-4, Emett Speer wrote:

Hello Everyone,

I would like to propose the exploration of adding a default PK setting do Django. This could be a flag at project creation time or a setting to be set before the first migration takes place.

This would allow the developer to set the default PK in Django to something like UUID. With this things like the default Group, User, etc.. models would have UUID based PK's rather then Int based ones and all future tables would have UUID PK's by default.

Please let me know what you think.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

[Josh Smeaton]

A major issue with this would be the many apps out in the wild (and their tests!) that assume the pk is an integer, and do queries like .filter(pk=1). I don't like the idea of being able to enforce a different kind of pk type for apps that you haven't written yourself.

Is there an actual problem having integer primary keys in standard apps and django that you're trying to work around? I can understand wanting uuids for the user model (for very large sites), but there's always the option of using custom user models for this. Permissions and Groups are unlikely to need uuids, and building such a system to swap out the actual type for a new one seems like massive overkill just to keep things consistent.

I'd be -0 on such a feature.

[Emett Speer]

My suggestion wouldn't be mandatory it would be more like a flag when you are starting a new project. So most people would likely never use it.

Well I think at this point its safe to say that this is not going to happen.

[Shai Berger]

On Thursday 01 September 2016 02:51:54 Josh Smeaton wrote:
> A major issue with this would be the many apps out in the wild (and their
> tests!) that assume the pk is an integer, and do queries like
> .filter(pk=1).

FWIW, this is a bad practice which we should recommend against. In databases
which rely on sequences, after you've run some tests, the pk of the first
record in a table is not necessarily 1 (because records in the table are
removed when test transactions are rolled back, but sequence values are not
re-used). Similar issues can arise in parallel execution of tests.

[This is a bit off-topic for the pk-type setting idea, I know]

Shai.

[Emett Speer]

I agree with you in recommending against using `.filter(pk=1)` in testing.

What do you think of the idea though. Do you think it would be worth looking into adding a flag for new projects or not worth the time/effort to add it.

[Marc Tamlyn]

For what it's worth I think this is *much* harder than it appears on the surface. Whilst setting another field as the PK is easy, setting another base type as an "auto" field is surprisingly tricky - lots of AutoField assumes integers.

However, I do think it has some merits. An obvious benefit to the consistency is when you are using another framework with Django which makes certain assumptions about the way you identify objects. Some front end frameworks prefer guids to integers, as would some security protocols.

M

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4422aad9-a9aa-4076-b24a-659c0594e4f9%40googlegroups.com.

[Aymeric Augustin]

I tend to agree with Marc.

While I’m less than enthusiastic about the prospect of adding a new setting for this, I noticed a few times in the past that Django's support for UUID PKs was buggy, perhaps in the admin (I don’t remember the details and I can’t say if all these bugs have been fixed).

First-class support for UUID PKs — which are strings, that’s the interesting property here — may require removing various shortcuts that assume integer PKs and that would be a good thing.

This is neither very concrete nor very helpful, sorry…

-- 

Aymeric.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1F9_ftSGLnaGQPp73CLrn6L167qVZMeTOOuasiTEWZSkg%40mail.gmail.com.

[Emett Speer]

I have not run into any issues with UUID PKs with Django 1.8 - 1.10 yet. If memory services me the UUIDFIeld in models is still relatively new at the moment.

-- 

Aymeric.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4422aad9-a9aa-4076-b24a-659c0594e4f9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Emett Speer]

I'm happy to hear that I'm not 100% alone on this one.

I also agree that this would be a much harder add then it may appear. Though I'm not suggesting any modifications to the AutoField I'm suggesting a setting that would make undefined ID fields in models UUID's by default rather then an Int. This would also need to change the current Django models from Int to UUID. I think it maybe best to have it as a flag when you start your project as the migration from Int to UUID can be rather painful.

On Monday, September 5, 2016 at 6:08:30 AM UTC-7, Marc Tamlyn wrote:

For what it's worth I think this is *much* harder than it appears on the surface. Whilst setting another field as the PK is easy, setting another base type as an "auto" field is surprisingly tricky - lots of AutoField assumes integers.

However, I do think it has some merits. An obvious benefit to the consistency is when you are using another framework with Django which makes certain assumptions about the way you identify objects. Some front end frameworks prefer guids to integers, as would some security protocols.

M

On 1 Sep 2016 5:49 p.m., "Emett Speer" <speer...@gmail.com> wrote:

I agree with you in recommending against using `.filter(pk=1)` in testing.

What do you think of the idea though. Do you think it would be worth looking into adding a flag for new projects or not worth the time/effort to add it.

On Wednesday, August 31, 2016 at 10:11:55 PM UTC-7, Shai Berger wrote:

On Thursday 01 September 2016 02:51:54 Josh Smeaton wrote:
> A major issue with this would be the many apps out in the wild (and their
> tests!) that assume the pk is an integer, and do queries like
> .filter(pk=1).

FWIW, this is a bad practice which we should recommend against. In databases
which rely on sequences, after you've run some tests, the pk of the first
record in a table is not necessarily 1 (because records in the table are
removed when test transactions are rolled back, but sequence values are not
re-used). Similar issues can arise in parallel execution of tests.

[This is a bit off-topic for the pk-type setting idea, I know]

Shai.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.