#399 (Bigint field object needed)
OleB
before the beta.
But at least for me (and probably for many others) this single ticket
can become a bigger show stopper than all the great tickets you have
been solving during the last days.
The 32 bit automatic primary key fields are simply too short. High
throughput sites can use the available keys up in a few years:
If you calculate with only 16 hours per internet day and 365.25 days
per year and create "only" 20 IDs per second, you would run out of IDs
shortly after 5 years.
Since model inheritance works it is possible to make elegant work
arounds. But using strings or the like is cumbersome and not good for
performance.
Bigint seems the clean way to go.
Best would be to have the automatic primary key fields use bigint. So
naive users wouldn't create time bombs.
The costs fog bigint in performance and space usage are negligible.
Best regards
Ole
George Vilches
> Best would be to have the automatic primary key fields use bigint. So
> naive users wouldn't create time bombs.
> The costs fog bigint in performance and space usage are negligible.
I'm -1 to this. >32-bit integers are not consistently implemented
across all of Django's supported DBs as auto-IDs, and anyone building
an app big enough to overflow the auto increment ID is going to be
advanced enough to know what resolutions are available to them for the
very long haul, and override models appropriately.
George
Martin Diers
On Aug 4, 2008, at 2:01 PM, George Vilches wrote:
>
> I'm -1 to this. >32-bit integers are not consistently implemented
> across all of Django's supported DBs as auto-IDs, and anyone building
> an app big enough to overflow the auto increment ID is going to be
> advanced enough to know what resolutions are available to them for the
> very long haul, and override models appropriately.
>
I agree. If someone has a DB with that many records, they have other
problems than bigint.
As to the rest, Back when this ticket was opened, it was a real pain
to implement a custom type. Now, it is so easy that it makes no sense
to implement this as a core feature.
See comment for example: http://code.djangoproject.com/ticket/399#comment
:38
Malcolm Tredinnick
On Mon, 2008-08-04 at 11:37 -0700, OleB wrote:
> Sorry for drawing your attention at this small ticket so shortly
> before the beta.
>
> But at least for me (and probably for many others) this single ticket
> can become a bigger show stopper than all the great tickets you have
> been solving during the last days.
As others have noted, not worth it at this point. You can make custom
fields easily now and you can also fairly easily alter the column type
of a primary key column if you want it to be able to store more than 4
billion rows. This isn't a show-stopper at all. There are at least two
work arounds.
Regards,
Malcolm