Comment créer des modèles de données flexibles dans Django avec JSONField et Pydantic

Dans cet article, je vais vous expliquer comment le JSONField de Django (un wrapper JSON et JSONB) peut être utilisé pour modéliser des données semi-structurées et comment vous pouvez appliquer un schéma sur cela. données à l'aide de Pydantic : une approche qui devrait sembler naturelle pour un développeur Web Python.

Définitions de types flexibles

Considérons un système qui traite les paiements, la table Transaction par exemple. Cela va ressembler à ceci :

from django.db import models

class Transaction(models.Model):
    # Other relevant fields...
    payment_method = models.JSONField(default=dict, null=True, blank=True)

nous nous concentrons sur le champ payment_method. Dans une situation réelle, nous aurons des méthodes existantes pour traiter les paiements :

• Carte de crédit

• PayPal

• Achetez maintenant, payez plus tard

• Crypto-monnaie

Notre système doit être adaptable pour stocker les données spécifiques requises par chaque mode de paiement tout en conservant une structure cohérente et validable.

Nous utiliserons Pydantic pour définir des schémas précis pour différents modes de paiement :

from typing import Optional
from pydantic import BaseModel

class CreditCardSchema(BaseModel):
    last_four: str
    expiry_month: int
    expiry_year: int
    cvv: str


class PayPalSchema(BaseModel):
    email: EmailStr
    account_id: str


class CryptoSchema(BaseModel):
    wallet_address: str
    network: Optional[str] = None


class BillingAddressSchema(BaseModel):
    street: str
    city: str
    country: str
    postal_code: str
    state: Optional[str] = None


class PaymentMethodSchema(BaseModel):
    credit_card: Optional[CreditCardSchema] = None
    paypal: Optional[PayPalSchema] = None
    crypto: Optional[CryptoSchema] = None
    billing_address: Optional[BillingAddressSchema] = None

Cette approche offre plusieurs avantages importants :

1. Un seul mode de paiement à la fois peut avoir une valeur non nulle.

2. Il est facile d'étendre ou de modifier sans migrations de bases de données complexes.

3. Garantit l'intégrité des données au niveau du modèle.

Pour appliquer un schéma sur notre champ payment_method, nous exploitons le modèle Pydantic pour garantir que toutes les données transmises au champ correspondent au schéma que nous avons défini.

from typing import Optional, Mapping, Type, NoReturn
from pydantic import ValidationError as PydanticValidationError
from django.core.exceptions import ValidationError

def payment_method_validator(value: Optional[dict]) -> Optional[Type[BaseModel] | NoReturn]:
    if value is None:
        return

    if not isinstance(value, Mapping):
        raise TypeError("Payment method must be a dictionary")

    try:
        PaymentMethodSchema(**value)
    except (TypeError, PydanticValidationError) as e:
        raise ValidationError(f"Invalid payment method: {str(e)}")

Ici, nous effectuons quelques vérifications pour nous assurer que les données entrant dans notre validateur sont du type correct afin que Pydantic puisse les valider. Nous ne faisons rien pour les valeurs nullables et nous générons une erreur de type si la valeur transmise n'est pas une sous-classe d'un type Mapping, comme un Dict ou un OrderedDict.

Lorsque nous créons une instance du modèle Pydantic en utilisant la valeur que nous transmettons au constructeur. Si la structure de la valeur ne correspond pas au schéma défini pour PaymentMethodSchema, Pydantic générera une erreur de validation. Par exemple, si nous transmettons une valeur e-mail non valide pour le champ e-mail dans PayPalSchema, Pydantic générera une erreur de validation comme celle-ci :

ValidationError: 1 validation error for PaymentMethodSchema
paypal.email
  value is not a valid email address: An email address must have an @-sign. [type=value_error, input_value='Check me out on LinkedIn: https://linkedin.com/in/daniel-c-olah', input_type=str]

Nous pouvons appliquer cette validation de deux manières :

1. Méthode de validation personnalisée

   Lors du processus de sauvegarde, nous appelons la fonction de validation pour nous assurer que le mode de paiement correspond au schéma attendu.
   

   from django.db import models
   
   class Transaction(models.Model):
       # ... other fields ...
       payment_method = models.JSONField(null=True, blank=True)
       def save(self, *args, **kwargs):
           # Override save method to include custom validation
           payment_method_validator(self.payment_method)
           super().save(*args, **kwargs)
   

   Bien qu'efficace, cette approche peut devenir lourde et moins idiomatique dans Django. Nous pourrions même remplacer la fonction par une méthode de classe qui fait la même chose pour rendre le code plus propre.

2. Utilisation des validateurs de terrain

   Cette méthode exploite le mécanisme de validation de champ intégré à Django :
   

   from django.db import models
   
   class Transaction(models.Model):
       # Other relevant fields...
       payment_method = models.JSONField(default=dict, null=True, blank=True)
   

   Cette approche équilibre flexibilité et contrôle sur les valeurs stockées dans le champ payment_method. Cela nous permet de nous adapter aux changements futurs des exigences sans compromettre l'intégrité des données existantes dans ce domaine. Par exemple, nous pourrions inclure un champ Paystack ID dans notre schéma Paystack. Ce changement se ferait en douceur, car nous n'aurions pas à gérer des migrations de bases de données complexes.

Nous pourrions même ajouter une méthode pay_later à l'avenir sans aucun problème. Les types de champs pourraient également changer, et nous ne serions pas confrontés à des contraintes de migration de champs de base de données, comme celles rencontrées lors de la migration de clés primaires entières vers des clés primaires UUID. Vous pouvez consulter le code complet ici pour comprendre complètement le concept.

Dénormalisation

La dénormalisation implique la duplication délibérée de données dans plusieurs documents ou collections afin d'optimiser les performances et l'évolutivité. Cette approche contraste avec la normalisation stricte utilisée dans les bases de données relationnelles traditionnelles, et les bases de données NoSQL ont joué un rôle déterminant dans la vulgarisation de la dénormalisation en introduisant des paradigmes de stockage flexibles et orientés documents.

Considérons un scénario de commerce électronique avec des tableaux séparés pour les produits et les commandes. Lorsqu'un client passe une commande, il est essentiel de capturer un instantané des détails du produit inclus dans le panier. Plutôt que de référencer les enregistrements de produits actuels, qui pourraient changer au fil du temps en raison de mises à jour ou de suppressions, nous stockons les informations sur les produits directement dans la commande. Cela garantit que la commande conserve son contexte et son intégrité d'origine, reflétant l'état exact des produits au moment de l'achat. La dénormalisation joue un rôle crucial dans l’atteinte de cette cohérence.

Une approche possible pourrait impliquer de dupliquer certains champs de produits dans le tableau des commandes. Cependant, cette méthode peut introduire des problèmes d’évolutivité et compromettre la cohésion du schéma de commande. Une solution plus efficace consiste à sérialiser les champs de produits pertinents dans une structure JSON, permettant à la commande de conserver un enregistrement autonome des produits sans recourir à des requêtes externes. Le code suivant illustre cette technique :

from typing import Optional
from pydantic import BaseModel

class CreditCardSchema(BaseModel):
    last_four: str
    expiry_month: int
    expiry_year: int
    cvv: str


class PayPalSchema(BaseModel):
    email: EmailStr
    account_id: str


class CryptoSchema(BaseModel):
    wallet_address: str
    network: Optional[str] = None


class BillingAddressSchema(BaseModel):
    street: str
    city: str
    country: str
    postal_code: str
    state: Optional[str] = None


class PaymentMethodSchema(BaseModel):
    credit_card: Optional[CreditCardSchema] = None
    paypal: Optional[PayPalSchema] = None
    crypto: Optional[CryptoSchema] = None
    billing_address: Optional[BillingAddressSchema] = None

Puisque nous avons couvert la plupart des concepts de la section précédente, vous devriez commencer à apprécier le rôle de Pydantic dans tout cela. Dans l'exemple ci-dessus, nous utilisons Pydantic pour valider une liste de produits liés à une commande. En définissant un schéma pour la structure du produit, Pydantic garantit que chaque produit ajouté à la commande répond aux exigences attendues. Si les données fournies ne sont pas conformes au schéma, Pydantic génère une erreur de validation.

Interroger JSONField dans Django

Nous pouvons interroger les clés JSONField de la même manière que nous effectuons des recherches dans les champs Django. Voici quelques exemples basés sur notre cas d'utilisation.

from typing import Optional, Mapping, Type, NoReturn
from pydantic import ValidationError as PydanticValidationError
from django.core.exceptions import ValidationError

def payment_method_validator(value: Optional[dict]) -> Optional[Type[BaseModel] | NoReturn]:
    if value is None:
        return

    if not isinstance(value, Mapping):
        raise TypeError("Payment method must be a dictionary")

    try:
        PaymentMethodSchema(**value)
    except (TypeError, PydanticValidationError) as e:
        raise ValidationError(f"Invalid payment method: {str(e)}")

Vous pouvez consulter la documentation pour en savoir plus sur le filtrage des champs JSON.

Conclusion

L'utilisation de JSON et JSONB dans PostgreSQL offre une grande flexibilité pour travailler avec des données semi-structurées dans des bases de données relationnelles. Des outils tels que Pydantic et JSONField de Django aident à appliquer des règles de structure des données, facilitant ainsi le maintien de l'exactitude et l'adaptation aux changements. Cette flexibilité doit toutefois être utilisée avec précaution. Sans une planification appropriée, cela peut entraîner un ralentissement des performances ou une complexité inutile à mesure que vos données évoluent au fil du temps.

Dans Django, les validateurs de champs ne sont déclenchés que lorsque full_clean() est explicitement appelé – cela se produit généralement lors de l'utilisation de Django Forms ou de l'appel de is_valid() sur les sérialiseurs DRF. Pour plus de détails, vous pouvez vous référer à la documentation du validateur Django.

Une approche plus avancée pour résoudre ce problème consisterait à implémenter un champ Django personnalisé qui intègre Pydantic pour gérer à la fois la sérialisation et la validation des données JSON en interne. Bien que cela justifie un article dédié, pour l'instant, vous pouvez explorer les bibliothèques qui proposent des solutions toutes faites à ce problème, par exemple : django-pydantic-jsonfield

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!