Django ORM可以以可靠的后端无关方式存储一个无符号的64位整数（又称ulong64还是uint64）？ [英] Can the Django ORM store an unsigned 64-bit integer (aka ulong64 or uint64) in a reliably backend-agnostic manner?

问题描述

我所看到的所有文档都意味着您可能可以这样做，但是没有任何官方的w / r / t ulong64 / uint64字段。有一些现成的选择在这个领域看起来很有希望：

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 ...几乎，但签署了;


• PositiveIntegerField ...可疑地32位看;和


• DecimalField ...用python表示的固定指针 decimal 类型，根据文档 - 这可能会转向成为一个类似的愚蠢和缓慢的数据库字段，当被剔除时，在DECIMAL或NUMERIC PostgreSQL类型。

• BigIntegerField ... almost, but signed;
• PositiveIntegerField ... suspiciously 32-bit-looking; and
• DecimalField ... a fixed-pointer represented with a python decimal 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.

...所有这些 像他们 可能存储一个这样的数字。除了他们的任何人都会提交，很像休·格兰特描绘的每一个rom-com角色。

... 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.

我的主要标准是，它适用于Django的支持的后端，没有任何如果postgresql（...）elif mysql（...） / code>类型的特殊情况废话。之后，需要速度 - 这是一个视觉数据库应用程序中的模型字段，它将索引图像派生数据（例如感知散列和提取的关键点特征），允许通过这些图像的内容进行排序和分组

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.

那么，有没有一个很好的Django扩展或应用，它提供了一些适合我的目的的 PositiveBigIntegerField ？

So: is there a good Django extension or app that furnishes some kind of PositiveBigIntegerField that will suit my purposes?

而且，禁止：如果有一个简单可靠的方式来使用Django的股票ORM来存储未签名的64位int，我想知道。看，我不是二进制的我必须在纸上做两个补充 - 所以如果你的这种方法涉及到一些位移诡计，不要犹豫，解释它是什么，即使它像你一样明显。感谢提前。

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.

推荐答案

虽然我没有测试，但你可能希望只是子类 BigIntegerField 。原来的 BigIntegerField 看起来像（ source here ）：

Although I did not test it, but you may wish to just subclass BigIntegerField. The original BigIntegerField looks like that (source here):

class BigIntegerField(IntegerField):
    empty_strings_allowed = False
    description = _("Big (8 byte) integer")
    MAX_BIGINT = 9223372036854775807

    def get_internal_type(self):
        return "BigIntegerField"

    def formfield(self, **kwargs):
        defaults = {'min_value': -BigIntegerField.MAX_BIGINT - 1,
                    'max_value': BigIntegerField.MAX_BIGINT}
        defaults.update(kwargs)
        return super(BigIntegerField, self).formfield(**defaults)

派生 PositiveBigIntegerField 可能如下所示：

class PositiveBigIntegerField(BigIntegerField):
    empty_strings_allowed = False
    description = _("Big (8 byte) positive integer")

    def db_type(self, connection):
        """
        Returns MySQL-specific column data type. Make additional checks
        to support other backends.
        """
        return 'bigint UNSIGNED'

    def formfield(self, **kwargs):
        defaults = {'min_value': 0,
                    'max_value': BigIntegerField.MAX_BIGINT * 2 - 1}
        defaults.update(kwargs)
        return super(PositiveBigIntegerField, self).formfield(**defaults)

虽然你应该在使用之前彻底测试，如果你这样做，请分享结果：）

Although you should test it thoroughly, before using it. If you do, please share the results :)

编辑：

我错过了一件事 - 内部数据库表示，这是基于 get_internal_type（），并存储列类型的定义，例如这里，如果是MySQL后端，并确定这里。它看起来像覆盖 db_type（） 将可以控制字段在数据库中的表示方式。但是，您需要通过检查连接参数找到一种方法来返回 db_type（）中的DBMS特定值。

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 overwriting db_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 in db_type() by checking connection argument.

这篇关于Django ORM可以以可靠的后端无关方式存储一个无符号的64位整数（又称ulong64还是uint64）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！