python - db_column - models django unique

¿Puede el ORM de Django almacenar un entero sin signo de 64 bits(también conocido como ulong64 o uint64) de una manera fiable y independiente del back-end?

Question

Todos los documentos que he visto implican que es posible que pueda hacerlo, pero no hay nada oficial w / r / t ulong64 / uint64 campos. Hay algunas opciones listas para usar que parecen bastante prometedoras en este campo:

• BigIntegerField ... casi, pero firmado;
• PositiveIntegerField ... sospechosamente de 32 bits; y
• DecimalField ... un puntero fijo representado con un tipo decimal python, de acuerdo con los documentos , que presumiblemente se convierte en un campo de base de datos lento y análogamente pedagógico cuando está almacenado, al estilo de los tipos PostgreSQL DECIMAL o NUMERIC.

... todos parecen guardar un número como ese. Excepto que NINGUNO DE ELLOS SE COMPROMETERÁ, al igual que todos los personajes rom-com interpretados por Hugh Grant.

Mi criterio principal es que funciona con los back-end compatibles de Django, sin ningún tipo de if postgresql (...) elif mysql (...) tipo de tonterías de casos especiales. Después de eso, existe la necesidad de velocidad, esto es para un campo de modelo en una aplicación de base de datos visual que indexará datos derivados de imágenes (p. Ej., Hashes perceptuales y funciones de punto clave extraídas), permitiendo ordenar y agrupar por el contenido de esas imágenes .

Entonces, ¿hay una buena extensión de Django o una aplicación que proporcione algún tipo de PositiveBigIntegerField que se adapte a mis propósitos?

Y, salvo eso: si hay una manera simple y confiable de usar el ORM en stock de Django para almacenar entradas de 64 bits sin firmar, me gustaría saberlo. Mira, no soy un genio binario; Tengo que hacer un complemento de dos en papel, así que si este método tuyo implica algún truco de cambio de bit, no dudes en explicar lo que es, incluso si te parece obvio. Gracias por adelantado.

Answer 1

Aunque no lo probé, es posible que desee simplemente subclasificar BigIntegerField . El BigIntegerField original se ve así ( fuente aquí ):

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)

Derivado PositiveBigIntegerField puede verse así:

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)

Aunque debes probarlo a fondo, antes de usarlo. Si lo haces, comparte los resultados :)

EDITAR :

Me perdí una cosa: la representación interna de la base de datos. Esto se basa en el valor devuelto por get_internal_type() y la definición del tipo de columna se almacena, por ejemplo. here en caso de backend MySQL y se determina here . Parece que sobrescribir db_type() le dará control sobre cómo se representa el campo en la base de datos. Sin embargo, deberá buscar una forma de devolver el valor específico de DBMS en db_type() revisando el argumento de connection .