All the docs I've seen imply that you might be able to do that, but there isn't anything official w/r/t ulong64/uint64 fields. There are a few off-the-shelf options that look quite promising in this arena:
BigIntegerField
... almost, but signed;PositiveIntegerField
... suspiciously 32-bit-looking; andDecimalField
... a fixed-pointer represented with a pythondecimal
type, according to the docs -- which presumably turns into an analogously pedantic and slow database field when socked away, á la the DECIMAL or NUMERIC PostgreSQL types.
... all of which look like they might store a number like that. Except NONE OF THEM WILL COMMIT, much like every single rom-com character portrayed by Hugh Grant.
My primary criterion is that it works with Django's supported backends, without any if postgresql (...) elif mysql (...)
type of special-case nonsense. After that, there is the need for speed -- this is for a model field in an visual-database application that will index image-derived data (e.g. perceptual hashes and extracted keypoint features), allowing ordering and grouping by the content of those images.
So: is there a good Django extension or app that furnishes some kind of PositiveBigIntegerField
that will suit my purposes?
And, barring that: If there is a simple and reliable way to use Django's stock ORM to store unsigned 64-bit ints, I'd like to know it. Look, I'm no binary whiz; I have to do two's complement on paper -- so if this method of yours involves some bit-shifting trickery, don't hesitate to explain what it is, even if it strikes you as obvious. Thanks in advance.
Although I did not test it, but you may wish to just subclass
BigIntegerField
. The originalBigIntegerField
looks like that (source here):Derived
PositiveBigIntegerField
may looks like this:Although you should test it thoroughly, before using it. If you do, please share the results :)
EDIT:
I missed one thing - internal database representation. This is based on value returned by
get_internal_type()
and the definition of the column type is stored eg. here in case of MySQL backend and determined here. It looks like overwritingdb_type()
will give you control over how the field is represented in the database. However, you will need to find a way to return DBMS-specific value indb_type()
by checkingconnection
argument.