L'ORM Django peut-il stocker un entier 64 bits non signé (alias ulong64 ou uint64) de manière fiable et indépendante du backend ?

Question

Tous les documents que j'ai vus impliquent que tu pourrait être capable de le faire, mais il n'y a rien d'officiel avec les champs ulong64/uint64.Il existe quelques options disponibles dans le commerce qui semblent très prometteuses dans ce domaine :

• BigIntegerField ...presque, mais signé ;
• PositiveIntegerField ...ressemblant étrangement à 32 bits ;et
• DecimalField ...un pointeur fixe représenté par un python decimal type, selon les documents -- qui se transforme vraisemblablement en un champ de base de données tout aussi pédant et lent lorsqu'il est supprimé, à la manière des types DECIMAL ou NUMERIC PostgreSQL.

...tout cela regarder comme eux pourrait stocker un numéro comme celui-là.Sauf qu'AUCUN D'EUX NE S'ENGAGERA, un peu comme tous les personnages de comédie romantique interprétés par Hugh Grant.

Mon principal critère est qu'il fonctionne avec les backends pris en charge par Django, sans aucun problème. if postgresql (...) elif mysql (...) une sorte d'absurdité particulière.Après cela, il faut de la rapidité : il s'agit d'un champ de modèle dans une application de base de données visuelle qui indexera les données dérivées d'images (par ex.hachages perceptuels et caractéristiques de points clés extraites), permettant le classement et le regroupement en fonction du contenu de ces images.

Donc:existe-t-il une bonne extension ou application Django qui fournit une sorte de PositiveBigIntegerField cela conviendra à mes besoins ?

Et à part ça :S'il existe un moyen simple et fiable d'utiliser l'ORM d'origine de Django pour stocker des entiers 64 bits non signés, j'aimerais le savoir.Écoutez, je ne suis pas un génie binaire ;Je dois faire le complément à deux sur papier - donc si votre méthode implique une astuce de déplacement de bits, n'hésitez pas à expliquer de quoi il s'agit, même si cela vous semble évident.Merci d'avance.

Answer 1

Bien que je ne l'ai pas testé, vous souhaiterez peut-être simplement sous-classer BigIntegerField.L'original BigIntegerField Ressemble à ça (source ici):

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)

Dérivé PositiveBigIntegerField peut ressembler à ceci :

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)

Bien que vous deviez le tester minutieusement avant de l’utiliser.Si vous le faites, partagez les résultats :)

MODIFIER:

J'ai raté une chose : la représentation interne de la base de données.Ceci est basé sur la valeur renvoyée par get_internal_type() et la définition du type de colonne est stockée par exemple. ici dans le cas du backend MySQL et déterminé ici.Cela ressemble à un écrasement db_type() vous donnera le contrôle sur la façon dont le champ est représenté dans la base de données.Cependant, vous devrez trouver un moyen de renvoyer la valeur spécifique au SGBD dans db_type() en vérifiant connection argument.