I submitted a patch to Django Ticket #399 (request for a bigint field type). It still needs testing but works at a quick glance on mysql. Here’s a shot of them in action from the admin interface (the input is just too small and just too big respectively):
BigIntegerField works perfectly on PostgreSQL but because it doesn’t have an unsigned integer type (that I can find),
PostitiveBigIntegerField isn’t going to make it all the way up to 18,446,744,073,709,551,615 without using an arbitrary precision
NUMERIC or mapping zero to -9,223,372,036,854,775,808. Both solutions are messy and it would be a shame to have the mysql and postgres backends behave so differently. As an aside, it looks like this is already the case with mysql’s
UNSIGNED while Postgres just checks to make sure that the integers are positive before inserting.
The best solution would probably be to employ backend-specific range checking for these monsterous numbers. That way you won’t end up out of range in PostgreSQL but you’re also not penalizing MySQL for being able to count to 18 bajillion. At this point it would be safe to drop in
BigIntegerField as is (as soon as I check it out on sqlite), but
PostitiveBigIntegerField still needs some pondering.
6 responses to “Django: Big Integer Fields”
Personally, I would penalize MySQL for violating the spec so eggregiously. Last I read, but it’s been a while, the SQL spec doesn’t discuss “unsigned” numbers. If you want to use unsigned numbers, I highly recommend you use a NUMERIC field of some sort to deal with it.
While I’m all for “cross platform” SQL, I’m also for throwing out any platform that dumbs things down too far. I know MySQL is popular, but it’s also heinously incompatible with PostgreSQL, Oracle, or any other commercial DB that I’m aware of.
helicopter skiing bis…
I think the author or something keep back