Options Meta des modèlesLien vers cette rubrique#

abstractLien vers cette rubrique#

Options.abstractLien vers cette définition#

Si abstract = True, ce modèle sera une classe de base abstraite.

app_labelLien vers cette rubrique#

Options.app_labelLien vers cette définition#

Si un modèle est défini en dehors d’une application dans INSTALLED_APPS, il doit déclarer à quelle application il appartient :

Code

app_label = "myapp"

Si vous souhaitez représenter un modèle avec le format étiquette_app.nom_objet ou étiquette_app.nom_modèle, vous pouvez respectivement utiliser model._meta.label ou model._meta.label_lower.

base_manager_nameLien vers cette rubrique#

Options.base_manager_nameLien vers cette définition#

Le nom d’attribut du gestionnaire à utiliser pour l’attribut _base_manager du modèle, par exemple 'objects'.

db_tableLien vers cette rubrique#

Options.db_tableLien vers cette définition#

Le nom de la table de base de données à utiliser pour le modèle :

Code

db_table = "music_album"

db_table_commentLien vers cette rubrique#

Options.db_table_commentLien vers cette définition#

Le commentaire sur la table de base de données à utiliser pour ce modèle. C’est utile pour documenter les tables de base de données pour ceux qui ont un accès direct à la base de données et qui ne lisent pas forcément votre code Django. Par exemple

class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    answer = models.TextField()

    class Meta:
        db_table_comment = "Question answers"

db_tablespaceLien vers cette rubrique#

Options.db_tablespaceLien vers cette définition#

Le nom de l’espace de tables de base de données à utiliser pour ce modèle. La valeur par défaut est le réglage DEFAULT_TABLESPACE du projet, s’il est défini. Si le moteur ne prend pas en charge les espaces de tables, cette option est ignorée.

default_manager_nameLien vers cette rubrique#

Options.default_manager_nameLien vers cette définition#

Le nom du gestionnaire à utiliser pour l’attribut _default_manager du modèle.

default_related_nameLien vers cette rubrique#

Options.default_related_nameLien vers cette définition#

Le nom qui sera utilisé par défaut pour la relation depuis un objet lié vers cet objet. La valeur par défaut est <nom_modèle>_set.

Cette option définit également related_query_name.

Comme le nom inverse d’un champ doit être unique, faites attention si vous créez une sous-classe du modèle. Pour contourner les collisions de noms, une partie du nom devrait contenir '%(app_label)s' et '%(model_name)s', qui sont respectivement remplacés par le nom de l’application contenant le modèle, et le nom du modèle, les deux en minuscules. Consultez le paragraphe sur les noms de liaison des modèles abstraits.

get_latest_byLien vers cette rubrique#

Options.get_latest_byLien vers cette définition#

Le nom d’un champ ou une liste de noms de champs du modèle, typiquement un champ DateField, DateTimeField ou IntegerField. Cette option définit le ou les champs par défaut à utiliser dans les méthodes latest() et earliest() du gestionnaire (Manager) du modèle.

Exemple :

Code

# Latest by ascending order_date.
get_latest_by = "order_date"

# Latest by priority descending, order_date ascending.
get_latest_by = ["-priority", "order_date"]

Voir la documentation de latest() pour plus de détails.

managedLien vers cette rubrique#

Options.managedLien vers cette définition#

La valeur par défaut est True, signifiant que Django crée les tables de base de données adéquates dans migrate ou dans le cadre des migrations et les efface dans le contexte de la commande d’administration flush. C’est-à-dire que Django pilote le cycle de vie des tables de la base de données.

Si la valeur est False, aucune opération de création, de modification ou de suppression de table de base de données n’est effectuée pour ce modèle. Utile si le modèle représente une table existante ou une vue de base de données qui a été créée par un autre moyen. C’est l’unique différence lorsque managed=False. Tous les autres aspects de la gestion des modèles sont traités comme pour un modèle normal. Cela inclut :

1. L’ajout automatique d’un champ de clé primaire au modèle si aucun n’est déclaré. Pour enlever toute confusion possible aux lecteurs de votre code, il est recommandé d’indiquer toutes les colonnes de la table de base de données que vous modélisez en utilisant des modèles non pilotés.

2. Si un modèle avec managed=False contient un champ ManyToManyField qui pointe vers un autre modèle non piloté, la table intermédiaire de la relation plusieurs-à-plusieurs ne sera pas non plus créée. Cependant, la table intermédiaire entre un modèle piloté et un modèle non piloté sera bel et bien créée.

   Si vous aimeriez changer ce comportement par défaut, créez explicitement le modèle de la table intermédiaire (avec l’option managed appropriée) et utilisez l’attribut ManyToManyField.through pour que la relation utilise le modèle ainsi créé.

En ce qui concerne les tests impliquant des modèles avec managed=False, c’est à vous de vous assurer que les tables correctes soient créées dans le cadre de la mise en place des tests.

Si vous êtes intéressé à modifier le comportement Python d’une classe de modèle, vous pourriez utiliser managed=False et créer une copie d’un modèle existant. Cependant, il existe une meilleure approche pour ce genre de situation : Modèles mandataires.

order_with_respect_toLien vers cette rubrique#

Options.order_with_respect_toLien vers cette définition#

Rend cet objet « triable » en fonction du champ donné, presque toujours un champ ForeignKey. Cela peut être utilisé pour permettre à des objets liés d’être triés en fonction d’un objet parent. Par exemple, si un objet Answer (réponse) est lié à un objet Question et qu’une question possède plus d’une réponse et que l’ordre des réponses est signifiant, voici comment cela serait défini :

Code

from django.db import models


class Question(models.Model):
    text = models.TextField()
    # ...


class Answer(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    # ...

    class Meta:
        order_with_respect_to = "question"

Lorsque order_with_respect_to est défini, deux méthodes complémentaires sont fournies pour récupérer et définir l’ordre des objets liés : get_RELATED_order() et set_RELATED_order(), où RELATED est le nom du modèle en minuscules. Par exemple, en supposant qu’un objet Question possède plusieurs objets Answer liés, la liste renvoyée contient les clés primaires des objets Answer liés :

Python console

>>> question = Question.objects.get(id=1)
>>> question.get_answer_order()
[1, 2, 3]

L’ordre des objets liés Answer d’un objet Question peut être défini en passant une liste de clés primaires d’objets Answer:

Python console

>>> question.set_answer_order([3, 1, 2])

Les objets liés reçoivent aussi deux méthodes, get_next_in_order() et get_previous_in_order(), qui peuvent être utilisées pour accéder à ces objets dans l’ordre correct. En supposant que les objets Answer sont triés par id:

Python console

>>> answer = Answer.objects.get(id=2)
>>> answer.get_next_in_order()
<Answer: 3>
>>> answer.get_previous_in_order()
<Answer: 1>

orderingLien vers cette rubrique#

Options.orderingLien vers cette définition#

Le tri par défaut des objets, lors de l’obtention de listes d’objets :

Code

ordering = ["-order_date"]

Il s’agit d’un tuple ou d’une liste de chaînes, ou d’expressions de requête. Chaque chaîne correspond à un nom de champ, facultativement préfixée par « - » indiquant un tri descendant. Les champs sans préfixe « - » sont triés dans l’ordre ascendant. Indiquez la chaîne « ? » pour trier de façon aléatoire.

Par exemple, pour trier sur un champ pub_date dans l’ordre ascendant, indiquez :

Code

ordering = ["pub_date"]

Pour trier par pub_date dans l’ordre descendant, indiquez :

Code

ordering = ["-pub_date"]

Pour trier par pub_date dans l’ordre descendant, puis par author dans l’ordre ascendant, indiquez :

Code

ordering = ["-pub_date", "author"]

Il est aussi possible d’utiliser des expressions de requête. Pour trier par author dans l’ordre croissant et pour que les valeurs nulles apparaissent en dernier, écrivez ceci

Code

from django.db.models import F

ordering = [F("author").asc(nulls_last=True)]

permissionsLien vers cette rubrique#

Options.permissionsLien vers cette définition#

Permissions supplémentaires à intégrer dans la table des permissions lors de la création de cet objet. Les permissions d’ajout, de modification, de suppression et d’affichage sont automatiquement créées pour tous les modèles. Cet exemple ajoute une permission supplémentaire, can_deliver_pizzas:

Code

permissions = [("can_deliver_pizzas", "Can deliver pizzas")]

Il s’agit d’une liste ou d’un tuple de tuples binaires dans le format (code_permission, nom_verbeux_permission).

default_permissionsLien vers cette rubrique#

Options.default_permissionsLien vers cette définition#

Contient ('add', 'change', 'delete', 'view') par défaut. Vous pouvez ajuster cette liste, par exemple en définissant une liste vide si votre application n’a besoin d’aucune permission par défaut. Les permissions doivent être définies pour le modèle avant que celui-ci ne soit créé par migrate afin d’éviter la création de permissions non utilisées.

proxyLien vers cette rubrique#

Options.proxyLien vers cette définition#

Si proxy = True, un modèle qui hérite d’un autre modèle sera considéré comme un modèle mandataire.

required_db_featuresLien vers cette rubrique#

Options.required_db_featuresLien vers cette définition#

Liste de fonctionnalités de base de données que la connexion en cours devrait avoir pour que le modèle soit considéré pendant la phase de migration. Par exemple, si cette liste contient ['gis_enabled'], le modèle ne sera synchronisé qu’avec les bases de données possédant des fonctionnalités SIG. Ceci est également utile pour omettre certains modèles lors de tests avec plusieurs moteurs de base de données différents. Évitez les relations avec ces modèles qui sont créés conditionnellement car l’ORM ne sait pas comment traiter ces cas.

required_db_vendorLien vers cette rubrique#

Options.required_db_vendorLien vers cette définition#

Nom d’un fournisseur de base de données pour lequel ce modèle est spécifique. Les noms des fournisseurs intégrés actuels sont : sqlite, postgresql, mysql et oracle. Si cet attribut n’est pas vide et que le fournisseur de la connexion actuelle ne correspond pas, le modèle n’est pas synchronisé.

select_on_saveLien vers cette rubrique#

Options.select_on_saveLien vers cette définition#

Détermine si Django utilise l’algorithme django.db.models.Model.save() d’avant la version 1.6. L’ancien algorithme utilise SELECT pour savoir s’il y a une ligne existant à mettre à jour. Le nouvel algorithme essaie directement un UPDATE. Dans de rares cas, la mise à jour par UPDATE d’une ligne existante n’est pas visible par Django. Un des exemples est le déclencheur ON UPDATE de PostgreSQL qui renvoie NULL. Dans de telles situations, le nouvel algorithme effectue finalement un INSERT même quand une ligne existe déjà dans la base de données.

Il n’y a habituellement pas besoin de définir cet attribut. La valeur par défaut est False.

Voir django.db.models.Model.save() pour plus de détails sur l’ancien et le nouvel algorithme d’enregistrement.

indexesLien vers cette rubrique#

Options.indexesLien vers cette définition#

Une liste des index que vous souhaitez définir pour le modèle :

Code

from django.db import models


class Customer(models.Model):
    first_name = models.CharField(max_length=100)
    last_name = models.CharField(max_length=100)

    class Meta:
        indexes = [
            models.Index(fields=["last_name", "first_name"]),
            models.Index(fields=["first_name"], name="first_name_idx"),
        ]

unique_togetherLien vers cette rubrique#

Options.unique_togetherLien vers cette définition#

Noms de champs qui forment ensemble des index uniques :

Code

unique_together = [["driver", "restaurant"]]

Il s’agit d’une liste de listes dont les valeurs combinées doivent être uniques. Utilisé dans l’administration de Django et appliqué au niveau base de données (c’est-à-dire que les commandes UNIQUE appropriées sont inclues dans les commandes CREATE TABLE).

Par commodité, unique_together peut être formé d’une seule liste lorsqu’un seul groupe de champs est défini :

Code

unique_together = ["driver", "restaurant"]

Il n’est pas possible d’inclure un champ ManyToManyField dans unique_together (il n’est même pas évident de savoir ce que ça signifierait). Si vous avez besoin de valider de l’unicité au niveau d’un champ ManyToManyField, essayez d’utiliser un signal ou un modèle through explicite.

L’exception ValidationError générée durant la validation du modèle lorsque la contrainte est violée possède le code d’erreur unique_together.

index_togetherLien vers cette rubrique#

Options.index_togetherLien vers cette définition#

Noms de champs qui forment ensemble des index :

Code

index_together = [
    ["pub_date", "deadline"],
]

Cette liste de champs formera un index combiné (c’est-à-dire que la commande CREATE INDEX appropriée sera produite).

Par commodité, index_together peut être formé d’une seule liste lorsqu’un seul groupe de champs est défini :

Code

index_together = ["pub_date", "deadline"]

constraintsLien vers cette rubrique#

Options.constraintsLien vers cette définition#

Une liste des contraintes que vous souhaitez définir pour le modèle :

Code

from django.db import models


class Customer(models.Model):
    age = models.IntegerField()

    class Meta:
        constraints = [
            models.CheckConstraint(check=models.Q(age__gte=18), name="age_gte_18"),
        ]

verbose_nameLien vers cette rubrique#

Options.verbose_nameLien vers cette définition#

Un nom verbeux pour l’objet, au singulier :

Code

verbose_name = "pizza"

Si cette option est absente, Django manipule le nom de la classe : CamelCase devient camel case.

verbose_name_pluralLien vers cette rubrique#

Options.verbose_name_pluralLien vers cette définition#

Le nom verbeux pluriel pour l’objet :

Code

verbose_name_plural = "stories"

Si cette option est absente, Django utilise verbose_name et y ajoute un « s ».

labelLien vers cette rubrique#

Options.labelLien vers cette définition#

Représentation de l’objet, renvoie app_label.object_name, par ex. 'polls.Question'.

label_lowerLien vers cette rubrique#

Options.label_lowerLien vers cette définition#

Représentation du modèle, renvoie app_label.model_name, par ex. 'polls.question'.