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):
Update: 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 IntegerFields being 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.
Comments
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.
Asian porn
porn comics
Good job.
helicopter skiing bis…
skiing helicopter…
I think the author or something keep back