Re: [Django] #8576: Multiple AutoFields in a model
Django
-------------------------------------+-------------------------------------
Reporter: honeyman | Owner: nobody
Type: Uncategorized | Status: closed
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution: wontfix
Keywords: multiple autofield | Triage Stage: Design
| decision needed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by logikonabstractions):
* ui_ux: => 0
* type: => Uncategorized
* severity: => Normal
* easy: => 0
Comment:
Know this is closed, but again just to provide perspective.
I could really have used this feature actually. I have a project with
existing data where they use as an ID an auto-increment (just like
Django's default id). However, they also use a different no_header.
Sometimes they create revision on their object, so basically their db ends
up looking like this:
id no_header suite
1 1 0
2 2 0
3 1 1
4 3 0
......
So essentially, the no_header is an auto-increment, that only increments
on the creation of new objects (with suite=0). If an object undergo some
specific operation, then its no_header remains the same, but suite += 1.
Which means that the no_header ends up running "behind" the id field, but
it still needs to be an auto-increment. Of course I can override save() &
do all that business there, but it would still be so much simpler to just
have 2 auto-increment fields. IMO this is a conception flaw in the
database backends - e.g there isn't an obvious reason to limit auto
increment to a single field, if a separate attributes allows specifying
what is a primary key. But I digress. Mostly wanted to illustrate a use
case.
--
Ticket URL: <https://code.djangoproject.com/ticket/8576#comment:9>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: honeyman | Owner: nobody
(models, ORM) |
Severity: Normal | Resolution:
| decision needed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* resolution: wontfix =>
* status: closed => new
Comment:
[https://code.djangoproject.com/ticket/373]
I'm looking to implement composite primary keys like this:
{{{
class Tenant(models.Model):
pass
class User(models.Model):
tenant = models.ForeignKey(Tenant, on_delete=models.CASCADE)
id = models.SmallAutoField()
class Meta:
primary_key = ("tenant_id", "id")
}}}
In order to encourage using surrogate keys in composite primary keys, it
would make a lot of sense to allow non-primary key auto fields.
We have the following options:
1. Remove the limitation for databases that support non-primary auto
fields altogether. We could allow non-primary key auto fields for
PostgreSQL, for example.
2. Refactor auto fields so that they are either primary keys OR part of a
composite primary key. This addresses my use case, but not the others.
3. Don't use auto fields in composite primary keys. We need an alternative
in this case.
--
Ticket URL: <https://code.djangoproject.com/ticket/8576#comment:10>