Getting Help

en
Langue : fr

1.10
1.11
2.0
2.1
2.2
3.0
3.1
3.2
4.0
4.1
4.2
5.0
5.1
dev
Version de la documentation : 1.8

Référence des champs de modèle¶

Ce document contient toutes les références d’API de Field, y compris les détails que Django met à disposition concernant les `options de champs`_ et les types de champs.

Voir aussi

Si les champs intégrés ne font pas l’affaire, vous pouvez essayer django-localflavor qui contient des bouts de code utiles pour un pays ou une culture particulière. Il est aussi possible d’écrire facilement son propre champ de modèle personnalisé.

Note

Techniquement, ces modèles sont définis dans django.db.models.fields, mais par commodité ils sont importés dans django.db.models ; la convention standard est d’utiliser from django.db import models et de se référer aux champs avec models.<Foo>Field.

Options des champs¶

Les paramètres suivants sont disponibles pour tous les types de champs. Tous sont facultatifs.

`null`¶

Field.null¶

Si la valeur est True, Django stocke les valeurs vides avec NULL dans la base de données. La valeur par défaut est False.

Évitez d’utiliser null pour des champs textuels comme CharField ou TextField, car les valeurs de chaîne vide sont toujours stockées avec la chaîne vide, pas comme NULL. Un champ textuel avec null=True implique qu’il y a deux valeurs possibles signifiant « pas de données » : NULL` et la chaîne vide. Dans la plupart des cas, il est redondant d’avoir deux valeurs possibles indiquant qu’il n’y a pas de données. La convention dans Django est d’utiliser la chaîne vide, pas NULL.

Pour les champs textuels comme pour les champs non textuels, il est aussi nécessaire de définir blank=True si vous voulez autoriser les valeurs vides dans les formulaires, puisque le paramètre null ne se rapporte qu’au stockage dans la base de données (voir blank).

Note

Lors de l’utilisation du moteur de base de données Oracle, c’est toujours la valeur NULL qui est stockée pour signifier que la chaîne est vide, quelle que soit la valeur de cet attribut.

Si vous souhaitez accepter des valeurs null avec BooleanField, utilisez plutôt NullBooleanField.

`blank`¶

Field.blank¶

Si la valeur est True, le champ peut être vide. La valeur par défaut est False.

Notez que c’est différent de null. null est purement lié à la base de données, alors que blank est lié à la validation. Quand un champ possède blank=True, la validation de formulaire permet la saisie de valeurs vides. Quand un champ possède blank=False, le champ doit être obligatoirement rempli.

`choices`¶

Field.choices¶

Un itérable (par exemple une liste ou un tuple) composé lui-même d’itérables de tuples binaires (par ex. [(A, B), (A, B) ...]) représentant les choix possibles pour ce champ. Si ce paramètre est présent, le composant de formulaire par défaut sera une liste déroulante contenant ces choix au lieu de la boîte de saisie de texte standard.

Le premier élément de chaque tuple est la valeur réelle à définir pour le modèle. Le second élément est la valeur visible par l’utilisateur. Par exemple :

YEAR_IN_SCHOOL_CHOICES = (
    ('FR', 'Freshman'),
    ('SO', 'Sophomore'),
    ('JR', 'Junior'),
    ('SR', 'Senior'),
)

Il est généralement conseillé de définir les choix à l’intérieur de la classe d’un modèle et de définir des constantes judicieusement nommées pour chaque valeur :

from django.db import models

class Student(models.Model):
    FRESHMAN = 'FR'
    SOPHOMORE = 'SO'
    JUNIOR = 'JR'
    SENIOR = 'SR'
    YEAR_IN_SCHOOL_CHOICES = (
        (FRESHMAN, 'Freshman'),
        (SOPHOMORE, 'Sophomore'),
        (JUNIOR, 'Junior'),
        (SENIOR, 'Senior'),
    )
    year_in_school = models.CharField(max_length=2,
                                      choices=YEAR_IN_SCHOOL_CHOICES,
                                      default=FRESHMAN)

    def is_upperclass(self):
        return self.year_in_school in (self.JUNIOR, self.SENIOR)

Bien qu’il soit possible de définir une liste de choix en dehors de la classe d’un modèle, puis de s’y référer, le fait de définir les choix et leurs étiquettes à l’intérieur de la classe du modèle permet de conserver toutes ces informations avec la classe qui les exploite ainsi que de faciliter la référence à ces choix (par exemple, Student.SOPHOMORE fonctionnera partout où le modèle Student a été importé).

Vous pouvez aussi arranger les choix possibles dans des groupes nommés qui pourront être utilisés à des fins d’organisation :

MEDIA_CHOICES = (
    ('Audio', (
            ('vinyl', 'Vinyl'),
            ('cd', 'CD'),
        )
    ),
    ('Video', (
            ('vhs', 'VHS Tape'),
            ('dvd', 'DVD'),
        )
    ),
    ('unknown', 'Unknown'),
)

Le premier élément de chaque tuple est le nom utilisé pour le groupe. Le second élément est un objet itérable de tuples binaires contenant la valeur et l’étiquette à afficher pour cette option. Les options groupées peuvent être combinées à des options non groupées dans une seule liste (comme l’option unknown dans cet exemple).

Pour chaque champ de modèle ayant l’option choices, Django ajoute une méthode pour obtenir l’étiquette à afficher selon la valeur actuelle du champ. Voir get_FOO_display() dans la documentation de l’API de base de données.

Notez que ces choix peuvent être constitués par n’importe quel objet itérable, et pas nécessairement par une liste ou un tuple. Ceci vous permet de construire dynamiquement la liste des choix. Mais si vous commencer à bidouiller l’attribut choices pour qu’il soit dynamique, il est probable qu’il soit plus judicieux d’utiliser une vraie table de base de données contenant une ForeignKey. choices est conçu pour les données statiques qui ne changent pas souvent, voire jamais.

New in Django 1.7.

À l’exception des cas où blank=False est défini pour le champ avec un contenu default, une étiquette contenant "---------" sera ajoutée à la liste de sélection. Pour surcharger ce comportement, ajoutez un tuple à choices contenant None. Par exemple, (None, 'Votre chaîne à afficher'). Il est aussi possible d’utiliser une chaîne vide au lieu de None lorsque c’est raisonnable, comme pour un champ CharField.

`db_column`¶

Field.db_column¶

Le nom de la colonne à utiliser pour ce champ dans la base de données. Si cet attribut est absent, Django utilise le nom du champ.

Si le nom de la colonne dans la base de données est un mot réservé en SQL ou s’il contient des caractères non autorisés dans le nom d’une variable Python (notamment, le trait d’union), ce n’est pas un souci. Django met entre guillemets les noms de table et de colonne de manière transparente.

`db_index`¶

Field.db_index¶

Si True, django-admin sqlindexes génère une instruction CREATE INDEX pour ce champ.

`db_tablespace`¶

Field.db_tablespace¶

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

`default`¶

Field.default¶

La valeur par défaut du champ. Cela peut être une valeur ou un objet exécutable. Dans ce dernier cas, l’objet est appelé lors de chaque création d’un nouvel objet.

La valeur par défaut ne peut pas être un objet mutant (instance de modèle, liste, set, etc.), car toutes les nouvelles instances du modèle utiliseraient une référence vers la même instance de cet objet. Au lieu de cela, imbriquez la valeur par défaut souhaitée dans un exécutable. Par exemple, si vous aviez un champ JSONField personnalisé et que vous vouliez lui fournir un dictionnaire comme valeur par défaut, utilisez une fonction comme ceci :

def contact_default():
    return {"email": "to1@example.com"}

contact_info = JSONField("ContactInfo", default=contact_default)

Notez que les fonctions lambda ne peuvent pas être utilisées comme options de champs tels que default car elles ne peuvent pas être sérialisées par les migrations. Consultez cette dernière documentation pour d’autres mises en garde.

La valeur par défaut est utilisée lorsque de nouvelles instances de modèle sont créées et qu’aucune valeur n’est fournie pour le champ. Lorsque le champ est une clé primaire, la valeur par défaut est aussi utilisée si le champ est défini à None.

Changed in Django 1.8:

La valeur par défaut n’était pas utilisée pour les valeurs None de clés primaires dans les versions précédentes.

`editable`¶

Field.editable¶

Si False, le champ ne sera pas affiché dans l’administration de Django, ni dans d’éventuels formulaires basés sur ModelForm. Il sera aussi omis dans la phase de validation de modèle. La valeur par défaut est True.

`error_messages`¶

Field.error_messages¶

Le paramètre error_messages permet de redéfinir les messages par défaut que le champ renvoie. Passez un dictionnaire dont les clés correspondent aux messages d’erreur que vous voulez redéfinir.

Les clés des messages d’erreur comprennent null, blank, invalid, invalid_choice, unique et unique_for_date. D’autres clés de messages d’erreur sont définies pour chaque champ de la section types de champs ci-dessous.

New in Django 1.7.

La clé de message d’erreur unique_for_date a été ajoutée.

`help_text`¶

Field.help_text¶

Texte d’aide supplémentaire à afficher avec le composant de formulaire. Utile pour la documentation même si le champ n’est pas utilisé dans un formulaire.

Notez que le HTML contenu dans cette valeur n’est pas échappé dans les formulaires générés automatiquement. Cela vous permet d’inclure du HTML dans help_text si vous le souhaitez. Par exemple :

help_text="Please use the following format: <em>YYYY-MM-DD</em>."

Accessoirement, vous pouvez utiliser du texte brut et django.utils.html.escape() pour échapper n’importe quel caractère spécial HTML. Assurez-vous d’échapper tout texte d’aide qui proviendrait d’utilisateurs non fiables afin d’éviter des attaques de script inter-site.

`primary_key`¶

Field.primary_key¶

Si la valeur est True, ce champ représentera la clé primaire du modèle.

Si vous n’indiquez aucun paramètre primary_key=True dans les champs d’un modèle, Django ajoute automatiquement un champ AutoField pour constituer une clé primaire ; il n’est donc pas nécessaire de définir le paramètre primary_key=True pour un champ sauf si vous souhaitez modifier le comportement par défaut de clé primaire automatique. Pour en savoir plus, consultez Champs clé primaire automatiques.

primary_key=True implique null=False et unique=True. Une seule clé primaire est autorisée par objet.

Le champ de clé primaire est en lecture seule. Si vous modifiez la valeur de la clé primaire d’un objet existant et que vous l’enregistrez, un nouvel objet est créé en parallèle à l’ancien.

`unique`¶

Field.unique¶

Si la valeur est True, ce champ doit être unique dans toute la table.

Cet attribut est appliqué au niveau de la base de données ainsi que dans la validation des modèles. Si vous essayez d’enregistrer une instance d’un modèle avec une valeur d’un champ unique dupliquée, une exception django.db.IntegrityError sera levée par la méthode save() du modèle.

Cette option est valide pour tous les types de champs, sauf pour ManyToManyField, OneToOneField et FileField.

Notez que lorsque unique vaut True, il n’est pas nécessaire de définir db_index, car unique implique qu’un index sera créé.

`unique_for_date`¶

Field.unique_for_date¶

Indiquez le nom d’un champ de type DateField ou DateTimeField comme valeur pour cette option, pour rendre obligatoire l’unicité de la valeur de ce champ en fonction de la valeur du champ date indiqué.

Par exemple, si vous avez un champ title qui a unique_for_date="pub_date", Django n’autorise pas la saisie de deux enregistrements avec le même title et la même pub_date.

Notez que si cet attribut est défini avec un objet DateTimeField, seule la partie date du champ est prise en compte. De plus, lorsque USE_TZ vaut True, le contrôle est effectué dans le fuseau horaire en cours au moment où l’objet est enregistré.

Cette contrainte est appliquée par Model.validate_unique() pendant la validation des modèles, et non pas au niveau de la base de données. Si une contrainte unique_for_date implique des champs qui ne font pas partie d’un formulaire ModelForm (par exemple si l’un des champs figure dans exclude ou que son attribut editable vaut False), Model.validate_unique() passe outre la validation de la contrainte concernée.

`unique_for_month`¶

Field.unique_for_month¶

Comme unique_for_date, mais requiert que le champ soit unique en rapport au mois du champ date.

`unique_for_year`¶

Field.unique_for_year¶

Comme unique_for_date et unique_for_month, mais avec l’année du champ date.

`verbose_name`¶

Field.verbose_name¶

Un nom humainement compréhensible pour le champ. Si cet attribut n’est pas renseigné, Django le crée automatiquement en utilisant le nom d’attribut du champ, en convertissant les soulignements en espaces. Voir noms de champs verbeux.

`validators`¶

Field.validators¶

Une liste de validateurs à exécuter pour ce champ. Consultez la documentation des validateurs pour plus d’informations.

Inscription et obtention d’expressions de recherche¶

Field implémente l’API d’inscription d’expressions de recherche. Cette API peut être utilisée pour personnaliser les recherches possibles pour une classe de champ et la manière d’obtenir ces recherches depuis un champ.

Types de champs¶

`AutoField`¶

class AutoField(**options)¶

Un champ IntegerField qui incrémente automatiquement sa valeur par rapport aux identifiants disponibles. Vous n’avez habituellement pas besoin d’utiliser ce champ directement ; un champ clé primaire est automatiquement ajouté au modèle s’il n’est pas explicitement défini. Voir Champs clé primaire automatiques.

`BigIntegerField`¶

class BigIntegerField(**options)¶

Un entier 64 bits, ressemblant à un IntegerField sauf qu’il garantit la couverture des nombres de -9223372036854775808 à 9223372036854775807. Le composant de formulaire par défaut de ce champ est un TextInput.

`BinaryField`¶

class BinaryField(**options)¶

Un champ pour stocker des données binaires brutes. Il ne peut recevoir que des octets (bytes). Il faut savoir que ce champ possède des fonctionnalités restreintes. Par exemple, il n’est pas possible de filtrer un jeu de requête par une valeur BinaryField.

Usage abusif de BinaryField

Bien qu’il puisse être tentant de vouloir stocker des fichiers dans la base de données, il s’agit d’une mauvaise idée dans 99 % des cas. Ce champ n’est pas une solution de remplacement d’une bonne gestion des fichiers statiques.

`BooleanField`¶

class BooleanField(**options)¶

Un champ vrai/faux.

Le composant de formulaire par défaut de ce champ est un CheckboxInput.

Si vous devez accepter les valeurs null, utilisez plutôt NullBooleanField.

La valeur par défaut de BooleanField est None lorsque Field.default n’est pas défini.

`CharField`¶

class CharField(max_length=None, **options)¶

Un champ pour les chaînes de caractères, courtes ou longues.

Pour une grande quantité de texte, utilisez TextField.

Le composant de formulaire par défaut de ce champ est un TextInput.

CharField a un paramètre obligatoire supplémentaire :

CharField.max_length¶: La taille maximale (en caractères) du champ. Cette taille est définie au niveau de la base de données et appliquée lors de la validation par Django.

Note

Si vous écrivez une application qui doit être portable sur plusieurs moteurs de base de données, il faut savoir qu’il y a des restrictions à propos de max_length pour certains de ces moteurs. Référez-vous aux notes sur les moteurs de base de données pour plus de détails.

Utilisateurs de MySQL

Si vous utilisez ce champ avec MySQLdb 1.2.2 et la collation utf8_bin (ce qui n’est pas le cas par défaut), il y a quelques problèmes dont il faut être conscient. Référez-vous aux notes sur la base de données MySQL pour plus de détails.

`CommaSeparatedIntegerField`¶

class CommaSeparatedIntegerField(max_length=None, **options)¶

Un champ d’entiers séparés par une virgule. Comme pour le champ CharField, le paramètre max_length est obligatoire ; la remarque au sujet de la portabilité entre les moteurs de base de données doit elle aussi être prise en compte.

`DateField`¶

class DateField(auto_now=False, auto_now_add=False, **options)¶

Une date, représentée en Python par une instance de datetime.date. Accepte quelques paramètres supplémentaires et facultatifs :

DateField.auto_now¶: Assigne automatiquement la valeur du champ à la date du jour lors de chaque enregistrement de l’objet. Utile pour les horodatages de « dernière modification ». Notez que c’est toujours la date actuelle qui est utilisée ; il ne s’agit pas seulement d’une valeur par défaut que l’on peut surcharger.

DateField.auto_now_add¶

Assigne automatiquement la valeur du champ à la date du jour lors du premier enregistrement de l’objet. Utile pour les horodatages de date de création. Notez que c’est toujours la date actuelle qui est utilisée ; il ne s’agit pas seulement d’une valeur par défaut que l’on peut surcharger. Ainsi, même si vous définissez une valeur pour ce champ lors de la création de l’objet, il sera ignoré. Si vous voulez pouvoir modifier ce champ, utilisez ce qui suit au lieu de définir auto_now_add=True:

Pour un champ DateField: default=date.today - de datetime.date.today()
Pour un champ DateTimeField: default=timezone.now - de django.utils.timezone.now()

Le composant de formulaire par défaut de ce champ est un TextInput. L’interface d’administration ajoute un calendrier JavaScript ainsi qu’un raccourci pour « Aujourd’hui ». Contient une clé supplémentaire de message d’erreur invalid_date.

Les options auto_now_add, auto_now et default sont mutuellement exclusives. Toute combinaison de ces options produira une erreur.

Note

Avec l’implémentation actuelle, si auto_now ou auto_now_add sont activés, les paramètres de champ suivants sont définis automatiquement : editable=False et blank=True.

Note

Les options auto_now et auto_now_add utilisent toujours la date dans le fuseau horaire par défaut au moment de la création ou de la mise à jour. Si vos besoins sont différents, vous pouvez envisager d’utiliser votre propre fonction de valeur par défaut ou de surcharger save() au lieu de faire appel à auto_now ou auto_now_add. Ou encore d’utiliser un champ DateTimeField au lieu d’un champ DateField et de décider de la manière de gérer la conversion d’une heure/date vers une date au moment de son affichage.

`DateTimeField`¶

class DateTimeField(auto_now=False, auto_now_add=False, **options)¶

Une date et une heure, représentées en Python par une instance de datetime.datetime. Ce champ accepte les mêmes paramètres supplémentaires que le champ DateField.

Le composant de formulaire par défaut de ce champ est un TextInput. L’interface d’administration utilise deux composants TextInput séparés avec des raccourcis JavaScript.

`DecimalField`¶

class DecimalField(max_digits=None, decimal_places=None, **options)¶

Un nombre décimal de taille fixe, représenté en Python par une instance de Decimal. Il requiert deux paramètres obligatoires :

DecimalField.max_digits¶: Le nombre maximum de chiffres autorisés dans le nombre. Notez que ce nombre doit être plus grand ou égal à decimal_places.

DecimalField.decimal_places¶: Le nombre de décimales à stocker avec le nombre.

Par exemple, pour enregistrer un nombre jusqu’à 999 avec une précision de 2 chiffres après la virgule, vous devriez utiliser :

models.DecimalField(..., max_digits=5, decimal_places=2)

Et pour enregistrer un nombre jusqu’à un milliard environ avec une précision de 10 chiffres après la virgule :

models.DecimalField(..., max_digits=19, decimal_places=10)

Le composant de formulaire par défaut de ce champ est un NumberInput lorsque localize vaut False, ou TextInput dans le cas contraire.

Note

Pour plus d’informations sur les différences entre les classes FloatField et DecimalField, consultez FloatField vs. DecimalField.

`DurationField`¶

New in Django 1.8.

class DurationField(**options)¶

Un champ pour stocker des périodes de temps, représentées en Python par des objets timedelta. Avec PostgreSQL, le type de données utilisé est un interval et avec Oracle, le type de données est INTERVAL DAY(9) TO SECOND(6). Sinon, c’est un grand nombre entier bigint de microsecondes qui est utilisé.

Note

L’arithmétique des champs DurationField fonctionne la plupart du temps. Cependant, pour toutes les bases de données autres que PostgreSQL, la comparaison de valeurs d’un champ DurationField avec l’arithmétique des instances DateTimeField ne fonctionne pas comme on pourrait l’espérer.

`EmailField`¶

class EmailField(max_length=254, **options)¶

Un champ CharField qui vérifie que sa valeur est une adresse électronique valide. Il utilise EmailValidator pour valider les valeurs saisies.

Changed in Django 1.8:

La valeur par défaut de max_length a été augmentée de 75 à 254 afin d’être conforme aux normes RFC3696/5321.

`FileField`¶

class FileField(upload_to=None, max_length=100, **options)¶

Un champ de fichier à téléverser.

Note

Les paramètres primary_key et unique ne sont pas pris en charge et génèrent une exception TypeError s’ils sont utilisés.

Possède deux paramètres facultatifs :

FileField.upload_to¶

Changed in Django 1.7:

upload_to était obligatoire dans les versions plus anciennes de Django.

Un chemin d’accès local qui sera ajouté au réglage MEDIA_ROOT pour déterminer la valeur de l’attribut url.

Ce chemin peut contenir des chaînes de format strftime() qui seront remplacées par la date/heure du fichier téléversé (permettant ainsi de ne pas remplir exagérément le répertoire indiqué).

Cet attribut peut aussi être un objet exécutable, comme une fonction, qui sera appelé pour obtenir le chemin de téléversement, incluant le nom du fichier. Cet objet exécutable doit accepter deux paramètres et renvoyer un chemin de type Unix (avec des barres obliques) qui sera transmis au système de stockage. Les deux paramètres passés sont :

Paramètre	Description
`instance`	Une instance du modèle où le champ `FileField` est défini. Plus spécifiquement, il s’agit de l’instance à laquelle le fichier actuel est joint. Dans la plupart des cas, cet objet n’aura pas encore été enregistré dans la base de données, donc en cas d’utilisation du champ `AutoField` par défaut, il pourrait bien ne pas avoir encore de valeur pour le champ de sa clé primaire.
`filename`	Le nom donné originellement au fichier. Sa prise en compte dans la détermination du chemin d’accès final n’est pas obligatoire.

Paramètre

Description

instance

Une instance du modèle où le champ FileField est défini. Plus spécifiquement, il s’agit de l’instance à laquelle le fichier actuel est joint.

Dans la plupart des cas, cet objet n’aura pas encore été enregistré dans la base de données, donc en cas d’utilisation du champ AutoField par défaut, il pourrait bien ne pas avoir encore de valeur pour le champ de sa clé primaire.

filename

Le nom donné originellement au fichier. Sa prise en compte dans la détermination du chemin d’accès final n’est pas obligatoire.

FileField.storage¶: Un objet de stockage, qui prend en charge l’enregistrement et la récupération des fichiers. Consultez Gestion des fichiers pour plus de détails sur la manière de fournir un tel objet.

Le composant de formulaire par défaut de ce champ est un ClearableFileInput.

L’utilisation d’un FileField ou d’un ImageField (voir ci-après) dans une classe de modèle se fait en quelques étapes :

Dans votre fichier de réglages, vous devez indiquer dans MEDIA_ROOT le chemin d’accès absolu vers un répertoire où Django enregistrera les fichiers téléversés (pour des raisons de performance, ces fichiers ne sont pas stockés en base de données). Indiquez dans MEDIA_URL l’URL publique de base correspondant à ce répertoire. Assurez vous que ce répertoire est accessible en écriture par l’utilisateur du serveur Web.
Ajoutez le champ FileField ou ImageField à votre modèle, en définissant l’option upload_to pour indiquer dans quel sous-répertoire de MEDIA_ROOT les fichiers doivent être téléversés.
Tout ce qui sera stocké dans la base de données est le chemin d’accès au fichier (relatif à MEDIA_ROOT). Il est très commode et courant d’utiliser l’attribut url offert par Django. Par exemple, considérant un ImageField nommé mug_shot, vous pouvez obtenir l’URL absolue de cette image dans un gabarit avec {{ object.mug_shot.url }}.

Par exemple, supposons que MEDIA_ROOT contient '/home/media' et que la valeur de upload_to est 'photos/%Y/%m/%d'. La partie '%Y/%m/%d' de upload_to est du formatage strftime() ; '%Y' correspond à l’année sur quatre chiffres, '%m' correspond au mois sur deux chiffres et '%d' correspond au jour sur deux chiffres. Si vous téléversez un fichier le 15 janvier 2007, il sera enregistré dans le répertoire /home/media/photos/2007/01/15.

Si vous souhaitez obtenir le nom du fichier téléversé ou sa taille, vous pouvez utiliser ses attributs name et size respectivement. Pour plus d’informations sur les attributs et méthodes disponibles, consultez la référence de la classe File et le guide thématique Gestion des fichiers.

Note

Le fichier est enregistré durant la phase d’enregistrement du modèle dans la base de données, il n’est donc pas possible de se baser sur le nom de fichier réel sur le disque tant que le modèle lui-même n’a pas été enregistré.

L’URL relative du fichier téléversé peut être obtenue en utilisant l’attribut url. En interne, c’est la méthode url() de la classe Storage sous-jacente qui est appelée.

Notez que chaque fois que vous avez affaire à des fichiers téléversés, vous devriez faire très attention à l’endroit où vous les enregistrez ainsi qu’à leur type, pour éviter toute faille de sécurité. Vérifiez tous les fichiers téléversés, ainsi vous serez sûr que ces fichiers sont bien ce qu’ils doivent être. Par exemple, si vous laissez quelqu’un téléverser aveuglément des fichiers sans les valider à destination d’un répertoire se trouvant sous la racine des documents de votre serveur Web, cette personne pourrait envoyer un script CGI ou PHP et le faire exécuter en visitant son URL sur votre site. Ne permettez pas cela.

Notez également que même l’envoi d’un fichier HTML peut poser des problèmes de sécurité équivalents aux attaques XSS ou CSRF, car ces fichiers peuvent être interprétés par un navigateur (même si le serveur n’est pas impliqué dans ce cas).

Les instances de FileField sont créées en tant que colonnes varchar dans la base de données avec une longueur par défaut maximale de 100 caractères. Comme pour d’autres champs, vous pouvez modifier la taille maximale en utilisant le paramètre max_length.

FileField et FieldFile¶

class FieldFile[source]¶

Lorsque vous accédez à un FileField d’un modèle, vous recevez une instance de FieldFile comme substitut d’accès au fichier sous-jacent. En plus des fonctionnalités héritées de django.core.files.File, cette classe possède plusieurs attributs et méthodes permettant d’interagir avec les données du fichier :

FieldFile.url¶

Une propriété en lecture seule pour accéder à l’URL relative du fichier, au travers de l’appel à la méthode url() de la classe Storage sous-jacente.

FieldFile.open(mode='rb')[source]¶

Même comportement que la méthode open() standard de Python et ouvre le fichier associé à l’instance actuelle dans le mode indiqué par mode.

FieldFile.close()[source]¶

Même comportement que la méthode file.close() standard de Python et ferme le fichier associé à l’instance actuelle.

FieldFile.save(name, content, save=True)[source]¶

Cette méthode accepte un nom de fichier et le contenu du fichier, les transmet à la classe de stockage du champ puis associe le fichier ainsi stocké avec le champ du modèle. Si vous souhaitez attribuer manuellement des données de fichier avec des instances FileField d’un modèle, la méthode save() est utilisée pour rendre persistantes ces données de fichier.

Requiert deux paramètres obligatoires : name correspondant au nom du fichier et content qui représente un objet contenant le contenu du fichier. Le paramètre facultatif save indique si l’instance de modèle doit être enregistrée après la modification du fichier associé à ce champ. Sa valeur par défaut est True.

Notez que le paramètre content doit être une instance de django.core.files.File, et non pas de l’objet file de Python. Vous pouvez construire une instance de File à partir d’un objet Python file existant comme ceci :

from django.core.files import File
# Open an existing file using Python's built-in open()
f = open('/path/to/hello.world')
myfile = File(f)

Ou il est aussi possible de le construire à partir d’une chaîne de caractères Python comme ceci :

from django.core.files.base import ContentFile
myfile = ContentFile("hello world")

Pour plus d’informations, voir Gestion des fichiers.

FieldFile.delete(save=True)[source]¶

Supprime le fichier associé à cette instance et efface tous les attributs du champ. Remarque : cette méthode ferme le fichier s’il se trouve être ouvert lorsque delete() est appelée.

Le paramètre facultatif save indique si l’instance de modèle doit être enregistrée après la suppression du fichier associé à ce champ. Sa valeur par défaut est True.

Notez que lorsqu’un modèle est supprimé, les fichiers liés ne sont pas supprimés. Si vous devez effacer les fichiers orphelins, c’est à vous de le faire (par exemple avec une commande de gestion personnalisée lancée manuellement ou programmée de manière périodique par un outil tel que cron).

`FilePathField`¶

class FilePathField(path=None, match=None, recursive=False, max_length=100, **options)¶

Un CharField dont les choix sont limités aux noms de fichiers dans un répertoire déterminé du système de fichiers. Il possède trois paramètres spéciaux, dont le premier est obligatoire :

FilePathField.path¶: Obligatoire. Le chemin d’accès absolu vers le répertoire dont le contenu fournit la source des choix du FilePathField. Exemple : "/home/images".

FilePathField.match¶: Facultatif. Une expression régulière sous forme de chaîne de caractères qui sera utilisée par FilePathField pour filtrer les noms de fichier. Notez que cette expression régulière sera appliquée au nom de fichier seul, et non pas à son chemin d’accès absolu. Exemple : "foo.*\.txt$" correspond au fichier foo23.txt, mais pas à bar.txt ni à foo23.png.

FilePathField.recursive¶: Facultatif. Vaut True ou False (valeur par défaut). Indique si tous les sous-répertoires de path doivent être inclus.

FilePathField.allow_files¶: Facultatif. Vaut True (valeur par défaut) ou False. Indique si les fichiers de l’emplacement spécifié doivent être inclus. Il faut que l’une des deux valeurs, ce champ ou allow_folders, soit True.

FilePathField.allow_folders¶: Facultatif. Vaut True ou False (valeur par défaut). Indique si tous les répertoires à l’intérieur de l’emplacement spécifié doivent être inclus. Il faut que l’une des deux valeurs, ce champ ou allow_files, soit True.

Ces paramètre peuvent bien sûr être utilisés conjointement.

Le piège potentiel est que match s’applique au nom du fichier uniquement, et non pas au chemin d’accès absolu. Donc, dans cet exemple :

FilePathField(path="/home/images", match="foo.*", recursive=True)

... correspondra à /home/images/foo.png mais pas à /home/images/foo/bar.png car match s’applique uniquement au nom du fichier (foo.png et bar.png).

Les instances de FilePathField sont créées en tant que colonnes varchar dans la base de données avec une longueur par défaut maximale de 100 caractères. Comme pour d’autres champs, vous pouvez modifier la taille maximale en utilisant le paramètre max_length.

`FloatField`¶

class FloatField(**options)¶

Un nombre flottant représenté en Python par une instance de float.

Le composant de formulaire par défaut de ce champ est un NumberInput lorsque localize vaut False, ou TextInput dans le cas contraire.

FloatField vs. DecimalField

La classe FloatField est parfois confondue avec la classe DecimalField. Même si elles représentent les deux des nombres réels, elles les stockent de manière différente. FloatField utilise en interne le type Python float alors que DecimalField utilise le type Python Decimal. Pour plus d’informations sur la différence entre ces deux types, consultez la documentation Python du module decimal.

`ImageField`¶

class ImageField(upload_to=None, height_field=None, width_field=None, max_length=100, **options)¶

Hérite de tous les attributs et méthodes de FileField, mais valide également que l’objet téléversé est une image valide.

En complément des attributs spéciaux disponibles pour FileField, un champ ImageField possède aussi les attributs height et width.

Pour faciliter l’interrogation de ces attributs, ImageField possède deux attributs facultatifs supplémentaires :

ImageField.height_field¶: Le nom d’un champ du modèle qui sera automatiquement renseigné avec la hauteur de l’image à chaque enregistrement de l’instance du modèle.

ImageField.width_field¶: Le nom d’un champ du modèle qui sera automatiquement renseigné avec la largeur de l’image à chaque enregistrement de l’instance du modèle.

Nécessite la bibliothèque Pillow.

Les instances de ImageField sont créées en tant que colonnes varchar dans la base de données avec une longueur par défaut maximale de 100 caractères. Comme pour d’autres champs, vous pouvez modifier la taille maximale en utilisant le paramètre max_length.

Le composant de formulaire par défaut de ce champ est un ClearableFileInput.

`IntegerField`¶

class IntegerField(**options)¶

Un nombre entier. Les valeurs de -2147483648 à 2147483647 sont acceptées par toutes les base de données prises en charge par Django. Le composant de formulaire par défaut de ce champ est un NumberInput lorsque localize vaut False, ou TextInput dans le cas contraire.

`IPAddressField`¶

class IPAddressField(**options)¶

Obsolète depuis la version 1.7: Ce champ a été déprécié en faveur de GenericIPAddressField.

Une adresse IP au format textuel (par ex. « 192.0.2.30 »). Le composant de formulaire par défaut de ce champ est un TextInput.

`GenericIPAddressField`¶

class GenericIPAddressField(protocol='both', unpack_ipv4=False, **options)¶

Une adresse IPv4 ou IPv6 au format textuel (par ex. 192.0.2.30 ou 2a02:42fe::4). Le composant de formulaire par défaut de ce champ est un TextInput.

La normalisation d’adresse IPv6 respecte la section 2.2 de la RFC 4291, y compris l’utilisation du format IPv4 suggéré dans le 3e paragraphe de cette section, comme ::ffff:192.0.2.0. Par exemple, 2001:0::0:01 sera normalisé en 2001::1 et ::ffff:0a0a:0a0a en ::ffff:10.10.10.10. Tous les caractères sont convertis en minuscules.

GenericIPAddressField.protocol¶: Limite la validité des saisies au protocole indiqué. Les valeurs possibles sont 'both' (les deux protocoles acceptés, valeur par défaut), 'IPv4' ou 'IPv6'.

GenericIPAddressField.unpack_ipv4¶: Décode les adresses IPv4 mappées comme ::ffff:192.0.2.1. Si cette option est activée, cette adresse serait décodée en 192.0.2.1. L’option est désactivée par défaut. Utilisable uniquement quand protocol est défini à 'both'.

Si vous autorisez les valeurs vierges, vous devez aussi autoriser les valeurs nulles, car les valeurs vierges sont stockées par une valeur nulle.

`NullBooleanField`¶

class NullBooleanField(**options)¶

Comme un champ BooleanField, mais autorise la valeur NULL comme choix possible. Préférez ce champ à un BooleanField avec l’option null=True. Le composant de formulaire par défaut de ce champ est un NullBooleanSelect.

`PositiveIntegerField`¶

class PositiveIntegerField(**options)¶

Comme un champ IntegerField, mais doit être un entier positif ou zéro (0). Les valeurs de 0 à 2147483647 sont acceptées par toutes les base de données prises en charge par Django. La valeur 0 est acceptée pour des raisons de rétrocompatibilité.

`PositiveSmallIntegerField`¶

class PositiveSmallIntegerField(**options)¶

Comme un PositiveIntegerField, mais n’autorise que des valeurs plus petites qu’un certain plafond (dépendant du moteur de base de données). Toutes les valeurs de 0 à 32767 sont acceptées par toutes les bases de données prises en charge officiellement par Django.

`SlugField`¶

class SlugField(max_length=50, **options)¶

Slug est un terme anglophone de journalisme. Un slug est une brève étiquette d’un contenu, composée uniquement de lettres, de chiffres, de soulignements ou de tirets. Ils sont généralement utilisés dans les URL.

Comme pour le champ CharField, vous pouvez indiquer le paramètre max_length (lisez les notes à propos de la portabilité entre bases de données de max_length). Si max_length n’est pas précisé, Django utilise la valeur 50 par défaut.

L’option Field.db_index est implicitement égale à True.

Il est souvent pratique de pouvoir automatiquement renseigner un SlugField en se basant sur la valeur d’un autre attribut. Vous pouvez le faire dans l’interface d’administration en utilisant prepopulated_fields.

`SmallIntegerField`¶

class SmallIntegerField(**options)¶

Comme un IntegerField, mais n’autorise que des valeurs plus petites qu’un certain plafond (dépendant du moteur de base de données). Toutes les valeurs de -32768 jusqu’à 32767 sont acceptées par toutes les bases de données prises en charge officiellement par Django.

`TextField`¶

class TextField(**options)¶

Un champ de texte long. Le composant de formulaire par défaut de ce champ est un Textarea.

Changed in Django 1.7:

Si vous indiquez un attribut max_length, celui-ci se répercute sur le composant Textarea du champ de formulaire généré automatiquement. Cependant, la limite n’est pas imposée au niveau du modèle, ni de la base de données. Pour cela, utilisez plutôt un champ CharField.

Utilisateurs de MySQL

Si vous utilisez ce champ avec MySQLdb 1.2.1p2 et la collation utf8_bin (ce qui n’est pas le cas par défaut), il y a quelques problèmes dont il faut être conscient. Référez-vous aux notes sur la base de données MySQL pour plus de détails.

`TimeField`¶

class TimeField(auto_now=False, auto_now_add=False, **options)¶

Une heure, représentée en Python par une instance de datetime.time. Ce champ accepte les mêmes options d’auto-complétion qu’un champ DateField.

Le composant de formulaire par défaut de ce champ est un TextInput. L’interface d’administration ajoute des raccourcis JavaScript.

`URLField`¶

class URLField(max_length=200, **options)¶

Un champ CharField pour les URL.

Le composant de formulaire par défaut de ce champ est un TextInput.

Comme pour les autres sous-classes de CharField, URLField accepte le paramètre facultatif max_length. Si vous ne renseignez pas la valeur de max_length, elle prend la valeur 200 par défaut.

`UUIDField`¶

New in Django 1.8.

class UUIDField(**options)¶

Un champ pour stocker des identifiants universels uniques (UUID). Utilise la classe Python UUID. Avec PostgreSQL, le type de données uuid est employé, sinon c’est un type char(32).

Les identifiants universels uniques sont une bonne alternative aux champs AutoField pour les clés primaires primary_key. La base de données ne produit pas de UUID à votre place, c’est pourquoi il est recommandé d’utiliser default:

import uuid
from django.db import models

class MyUUIDModel(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)
    # other fields

Notez que nous passons bien un objet exécutable (sans les parenthèses) à default, et non pas une instance de UUID.

Référence d’API des champs¶

class Field¶

Field est une classe abstraite qui représente une colonne de table de base de données. Django utilise des champs pour créer une table de base de données (db_type()), pour faire correspondre des types Python à une base de données (get_prep_value()) et inversement (from_db_value()), et pour appliquer la API de référence des expressions de recherche (get_prep_lookup()).

Un champ est donc une pièce essentielle dans différentes API de Django, notamment pour les modèles et les jeux de requête.

Dans les modèles, un champ est instancié comme attribut de classe et représente une colonne de table de base de données, voir Modèles. Il possède des attributs comme null et unique, ainsi que des méthodes que Django utilise pour faire correspondre la valeur du champ à des valeurs spécifiques à la base de données.

Un champ Field est une sous-classe de RegisterLookupMixin, ce qui fait qu’à la fois Transform et Lookup peuvent y être inscrits pour être exploités dans les requêtes QuerySet (par ex. nom_champ__exact="foo"). Toutes les :ref:expressions de requête intégrées <field-lookups>` sont inscrites par défaut.

Tous les types de champs fournis par Django, tels que CharField, sont des implémentations dérivées de Field. Si vous avez besoin d’un nouveau type de champ, vous pouvez soit hériter d’un des champs de Django ou écrire une classe Field à partir de zéro. Dans tous les cas, consultez Écriture de champs de modèles personnalisés.

description¶

Une description verbeuse du champ, par exemple pour l’application django.contrib.admindocs.

La description peut prendre la forme :

description = _("String (up to %(max_length)s)")

où les paramètres sont interpolés à partir du __dict__ du champ.

Pour faire correspondre un champ Field à un type particulier d’une base de données, Django expose deux méthodes :

get_internal_type()¶

Renvoie une chaîne nommant ce champ à l’usage du moteur de base de données spécifique. Par défaut, c’est le nom de la classe qui est renvoyé.

Voir Émulation de types de champs intégrés pour son utilisation dans des types de champs personnalisés.

db_type(connection)¶

Renvoie le type de donnée de la colonne de la base de données de la classe Field, prenant en compte l’objet connection.

Voir Types de base de données personnalisés pour son utilisation dans des types de champs personnalisés.

Il existe trois situations principales où Django a besoin de faire interagir le moteur de base de données et les champs :

lorsqu’il interroge la base de données (valeur Python -> valeur pour le moteur de base de données)
lorsqu’il charge des données à partir de la base de données (valeur du moteur de base de données -> valeur Python)
lorsqu’il enregistre vers la base de données (valeur Python -> valeur pour le moteur de base de données)

Lors d’une interrogation, get_db_prep_value() et get_prep_value() sont utilisés :

get_prep_value(value)¶

value est la valeur actuelle de l’attribut de modèle, et la méthode doit renvoyer les données dans un format préparé spécialement pour être utilisé comme paramètre de la requête.

Voir Conversion d’objets Python en valeurs de requête pour son utilisation.

get_db_prep_value(value, connection, prepared=False)¶

Convertit value vers une valeur spécifique au moteur de base de données. Par défaut, il renvoie value si prepared=True et get_prep_value() sinon.

Voir Conversion de valeurs de requête en valeurs de base de données pour son utilisation.

Lors du chargement de données, from_db_value() est utilisé :

from_db_value(value, expression, connection, context)¶

New in Django 1.8.

Convertit la valeur renvoyée par la base de données en un objet Python. C’est l’inverse de get_prep_value().

Cette méthode n’est pas utilisée pour la plupart des champs intégrés, car le moteur de base de données renvoie déjà le bon type Python, ou le moteur se charge lui-même de la conversion.

Voir Conversion de valeurs en objets Python pour son utilisation.

Note

Pour des raisons de performance, from_db_value n’est pas implémentée comme opération blanche pour les champs qui n’en ont pas besoin (tous les champs Django). Par conséquent, vous ne pouvez pas appeler super dans votre définition.

Lors de l’enregistrement, pre_save() et get_db_prep_save() sont utilisés :

get_db_prep_save(value, connection)¶: Comme pour get_db_prep_value(), mais appelé lorsque la valeur du champ doit être enregistrée dans la base de données. Renvoie par défaut get_db_prep_value().

pre_save(model_instance, add)¶

Méthode appelée avant get_db_prep_save() pour préparer la valeur avant d’être enregistrée (par ex. pour DateField.auto_now).

model_instance est l’instance à laquelle appartient ce champ et add indique si l’instance est enregistrée dans la base de données pour la première fois.

Cette méthode doit renvoyer la valeur de l’attribut correspondant de model_instance pour ce champ. Le nom d’attribut est dans self.attname (défini par Field).

Voir Pré-traitement des valeurs avant enregistrement pour son utilisation.

Lorsqu’un champ est interrogé, sa valeur peut avoir besoin de « préparation ». Django expose deux méthodes à cet effet :

get_prep_lookup(lookup_type, value)¶

Prépare value en fonction de la base de données avant de pouvoir être utilisée dans une expression d’interrogation. lookup_type corresponond à l’un des filtres d’interrogation valides de Django : "exact", "iexact", "contains", "icontains", "gt", "gte", "lt", "lte", "in", "startswith", "istartswith", "endswith", "iendswith", "range", "year", "month", "day", "isnull", "search", "regex" et "iregex".

New in Django 1.7.

Si vous utilisez une expression personnalisée, lookup_type peut correspondre à n’importe quel nom lookup_name inscrit pour ce champ.

Voir Préparation des valeurs pour la recherche en base de données pour son utilisation.

get_db_prep_lookup(lookup_type, value, connection, prepared=False)¶

Semblable à get_db_prep_value(), mais dans un but d’interrogation.

Tout comme pour get_db_prep_value(), la connexion qui sera utilisée pour la requête est transmise par le paramètre connection. De plus, le paramètre prepared indique si la valeur a déjà été préparée par get_prep_lookup().

Les champs reçoivent souvent leur valeur dans un type différent, que ce soit par la sérialisation ou par les formulaires.

to_python(value)¶

Convertit la valeur dans le bon objet Python. Elle opère à l’inverse de value_to_string() et est également appelée dans clean().

Voir Conversion de valeurs en objets Python pour son utilisation.

En plus de l’enregistrement dans la base de données, le champ doit aussi savoir comment sérialiser sa valeur :

value_to_string(obj)¶

Convertit obj en une chaîne. Utilisé pour sérialiser la valeur du champ.

Voir Conversion des données de champs pour la sérialisation pour son utilisation.

Lors de l’utilisation de formulaires de modèles, le champ Field doit savoir quel champ de formulaire doit le représenter en appelant :

formfield(form_class=None, choices_form_class=None, **kwargs)¶

Renvoie le champ de formulaire django.forms.Field utilisé par défaut pour ce champ dans un formulaire ModelForm.

Par défaut, si form_class et choices_form_class valent les deux None, c’est un champ CharField qui sera renvoyé ; si choices_form_class est renseigné, ce sera un champ TypedChoiceField.

Voir Sélection du champ de formulaire pour un champ de modèle pour son utilisation.

deconstruct()¶

New in Django 1.7.

Renvoie un tuple à 4 éléments avec suffisamment d’informations pour recréer le champ :

Le nom du champ dans le modèle.
Le chemin d’importation du champ (par ex. "django.db.models.IntegerField"). Il est recommandé d’indiquer la version la plus portable, donc moins le chemin est spécifique, mieux c’est.
Une liste de paramètres positionnels.
Un dictionnaire de paramètres nommés.

Cette méthode doit être ajoutée aux champs créés avant la version 1.7 afin de pouvoir migrer leurs données en utilisant les Migrations.

Référence d’attributs des champs¶

New in Django 1.8.

Chaque instance Field contient plusieurs attributs qui permettent d’inspecter son comportement. Utilisez ces attributs plutôt que de vous baser sur des contrôles de type isinstance lorsque vous avez besoin d’écrire du code qui dépend de la fonctionnalité d’un champ. Ces attributs peuvent être utilisée conjointement avec l’API Model._meta pour préciser une recherche de types de champs spécifiques. Les champs de modèles personnalisés devraient implémenter ces drapeaux.

Attributs pour les champs¶

Field.auto_created¶: Drapeau booléen indiquant si le champ a été créé automatiquement, comme pour le champ OneToOneField utilisé dans un contexte d’héritage de modèles.

Field.concrete¶: Drapeau booléen indiquant si le champ est associé à une colonne de base de données.

Field.hidden¶: Drapeau booléen indiquant si un champ est utilisé pour appuyer la fonctionnalité d’un autre champ non masqué (par ex. les champs content_type et object_id qui constituent une relation GenericForeignKey). Le drapeau hidden est utilisé pour distinguer ce qui constitue le sous-ensemble public des champs du modèle de tous les champs du modèle.

Note

Options.get_fields() exclut par défaut les champs masqués. Indiquez include_hidden=True pour renvoyer les champs masqués dans sa réponse.

Field.is_relation¶: Drapeau booléen indiquant si un champ contient des références à un ou plusieurs autres modèles pour sa fonctionnalité (par ex. ForeignKey, ManyToManyField, OneToOneField, etc.).

Field.model¶: Renvoie le modèle dans lequel le champ est défini. Si un champ est défini dans la classe parent d’un modèle, model désigne alors la classe parente, et non pas la classe de l’instance.

Attributs pour les champs de relation¶

Ces attributs sont utilisés pour interroger la cardinalité et d’autres détails d’une relation. Ces attributs sont présents sur tous les champs ; cependant, ils n’ont des valeurs booléennes (plutôt que None) que si le champ est de type relationnel (Field.is_relation=True).

Field.many_to_many¶: Drapeau booléen qui vaut True si le champ est une relation plusieurs-à-plusieurs ; False sinon. Le seul champ inclus dans Django pour lequel cet attribut vaut True est ManyToManyField.

Field.many_to_one¶: Drapeau booléen qui vaut True si le champ est une relation plusieurs-à-un, comme pour un champ ForeignKey ; False sinon.

Field.one_to_many¶: Drapeau booléen qui vaut True si le champ est une relation un-à-plusieurs, comme pour GenericRelation ou la contrepartie d’une clé ForeignKey ; False sinon.

Field.one_to_one¶: Drapeau booléen qui vaut True si le champ est une relation un-à-un, comme pour un champ OneToOneField ; False sinon.

Field.related_model¶: Pointe vers le modèle en lien avec le champ. Par exemple, Author dans ForeignKey(Author). Si un champ est une relation générique (tel que GenericForeignKey ou GenericRelation), related_model vaut None.

Modèles

L’API _meta des modèles

Documentation

Référence des champs de modèle¶

Options des champs¶

null¶

blank¶

choices¶

db_column¶

db_index¶

db_tablespace¶

default¶

editable¶

error_messages¶

help_text¶

primary_key¶

unique¶

unique_for_date¶

unique_for_month¶

unique_for_year¶

verbose_name¶

validators¶

Inscription et obtention d’expressions de recherche¶

Types de champs¶

AutoField¶

BigIntegerField¶

BinaryField¶

BooleanField¶

CharField¶

CommaSeparatedIntegerField¶

DateField¶

DateTimeField¶

DecimalField¶

DurationField¶

EmailField¶

FileField¶

FileField et FieldFile¶

FilePathField¶

FloatField¶

ImageField¶

IntegerField¶

IPAddressField¶

GenericIPAddressField¶

NullBooleanField¶

PositiveIntegerField¶

PositiveSmallIntegerField¶

SlugField¶

SmallIntegerField¶

TextField¶

TimeField¶

URLField¶

UUIDField¶

Champs pour les relations¶

ForeignKey¶

Représentation en base de données¶

Paramètres¶

ManyToManyField¶

Représentation en base de données¶

Paramètres¶

OneToOneField¶

Référence d’API des champs¶

Référence d’attributs des champs¶

Attributs pour les champs¶

Attributs pour les champs de relation¶

Informations supplémentaires

Support Django!

Sommaire

Parcourir

Vous êtes ici :

Obtenir de l'aide

Télécharger :

`null`¶

`blank`¶

`choices`¶

`db_column`¶

`db_index`¶

`db_tablespace`¶

`default`¶

`editable`¶

`error_messages`¶

`help_text`¶

`primary_key`¶

`unique`¶

`unique_for_date`¶

`unique_for_month`¶

`unique_for_year`¶

`verbose_name`¶

`validators`¶

`AutoField`¶

`BigIntegerField`¶

`BinaryField`¶

`BooleanField`¶

`CharField`¶

`CommaSeparatedIntegerField`¶

`DateField`¶

`DateTimeField`¶

`DecimalField`¶

`DurationField`¶

`EmailField`¶

`FileField`¶

`FilePathField`¶

`FloatField`¶

`ImageField`¶

`IntegerField`¶

`IPAddressField`¶

`GenericIPAddressField`¶

`NullBooleanField`¶

`PositiveIntegerField`¶

`PositiveSmallIntegerField`¶

`SlugField`¶

`SmallIntegerField`¶

`TextField`¶

`TimeField`¶

`URLField`¶

`UUIDField`¶

`ForeignKey`¶

`ManyToManyField`¶

`OneToOneField`¶