That being said, I guess it's a good idea to start with a serial field. A
serial is a 4 byte integer with an implicit sequence. Ergo its and auto
increment field for none primary keys! Yeah!
**Usecase:** You could have a customer number, or invoice number in your
code. Usually it is a good idea to not use a natural primary key,
therefore reusing the pk as that number could be considered bad. Having a
separate field with a separate sequence solves this issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/27452>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Old description:
> Since we have the beautiful `contrib.postgres` package now, we can add a
> couple more Postgres specific fields, that are not supported by MySQL but
> handy to all the Postgres fan boys.
>
> That being said, I guess it's a good idea to start with a serial field. A
> serial is a 4 byte integer with an implicit sequence. Ergo its and auto
> increment field for none primary keys! Yeah!
>
> **Usecase:** You could have a customer number, or invoice number in your
> code. Usually it is a good idea to not use a natural primary key,
> therefore reusing the pk as that number could be considered bad. Having a
> separate field with a separate sequence solves this issue.
New description:
Since we have the beautiful `contrib.postgres` package now, we can add a
couple more Postgres specific fields, that are not supported by MySQL but
handy to all the Postgres fan boys.
That being said, I guess it's a good idea to start with `Serial`.
The PostgreSQL documentation: https://www.postgresql.org/docs/9.1/static
/datatype-numeric.html describes the field as follows:
The data types `serial` and `bigserial` are not true types, but merely a
notational convenience for creating unique identifier columns (similar to
the AUTO_INCREMENT property supported by some other databases).
**Use Cases:**
1. Anywhere an automatic incrementing value is required, but a primary key
is often (mis)used.
2. Providing additional (user controlled) auto-incrementing values.
The primary benefit is that is isolates the primary key for the sole use
of maintaining referential integrity.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:1>
Comment (by Johannes Hoppe):
I opened a PR with an implementation that I am already using somewhere. It
added a couple of tests and documentation too.
I guess this is a good starting point for a discussion.
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:2>
* owner: (none) => Johannes Hoppe
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:3>
* needs_better_patch: 0 => 1
* has_patch: 0 => 1
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:4>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:5>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:6>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:7>
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:8>
* version: 1.10 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:9>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:10>
* needs_better_patch: 0 => 1
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:11>
* cc: InvalidInterrupt (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:12>
Comment (by Johannes Hoppe):
I closed my PR for now, due to a lack of interest. Since Django does
support returning values since v3.0 everyone who needs such a field can
build it. Yet, I don't have the time get the feature into Django for now.
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:13>
Comment (by InvalidInterrupt):
Replying to [comment:13 Johannes Hoppe]:
> I closed my PR for now, due to a lack of interest. Since Django does
support returning values since v3.0 everyone who needs such a field can
build it. Yet, I don't have the time get the feature into Django for now.
Do you mind if I continue working on this using your branch? Handling
sequence resets after loading fixtures will require changes to the DB
backend.
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:14>
* owner: Johannes Hoppe => (none)
* status: assigned => new
Comment:
Latest comment from Johannes is clearly an invitation to help :-)
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:15>
* needs_better_patch: 1 => 0
* needs_tests: 1 => 0
Comment:
[https://github.com/django/django/pull/12989 New PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:17>
* needs_better_patch: 0 => 1
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:18>
* needs_better_patch: 1 => 0
* needs_tests: 1 => 0
Comment:
[https://github.com/django/django/pull/13580 New PR for Default
Expression]
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:19>
* needs_docs: 0 => 1
* needs_tests: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:21>
Comment (by Claude Paroz):
Does this still make sense now that Django is using identity columns for
`*AutoField`s?
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:22>
Comment (by Simon Charette):
Claude, yes I think that the move to identity columns on Postgres made
this feature even more desirable (e.g. #34131).
--
Ticket URL: <https://code.djangoproject.com/ticket/27452#comment:23>