Toutes ces opérations sont disponibles dans le module django.contrib.postgres.operations.
Il est possible de créer une extension de base de données PostgreSQL en utilisant un fichier de migration. Cet exemple crée une extension hstore, mais le même principe est applicable aux autres extensions.
\nConfigurer l’extension hstore dans PostgreSQL avant la première opération CreateModel ou AddField qui concerne un champ HStoreField en ajoutant une migration comprenant l’opération HStoreExtension. Par exemple :
from django.contrib.postgres.operations import HStoreExtension\n\n\nclass Migration(migrations.Migration):\n ...\n\n operations = [HStoreExtension(), ...]\nL’opération omet l’ajout de l’extension si celle-ci existe déjà.
\nPour la plupart des extensions, il est nécessaire que l’utilisateur de base de données possède les droits de superutilisateur. Si l’utilisateur de base de données Django ne possède pas les privilèges suffisants, il est alors nécessaire de créer l’extension en dehors des migrations Django avec un utilisateur qui possède ces droits. Dans ce cas, connectez-vous à la base de données et lancez la requête CREATE EXTENSION IF NOT EXISTS hstore;.
CreateExtensionLien vers cette rubrique#Une sous-classe d”Operation qui installe une extension PostgreSQL. Pour les extensions courantes, utilisez l’une des sous-classes plus spécifiques ci-dessous.
Ce paramètre est obligatoire. Le nom de l’extension à installer.
\nBloomExtensionLien vers cette rubrique#Installe l’extension bloom.
BtreeGinExtensionLien vers cette rubrique#Installe l’extension btree_gin.
BtreeGistExtensionLien vers cette rubrique#Installe l’extension btree_gist.
CITextExtensionLien vers cette rubrique#Installe l’extension citext.
CryptoExtensionLien vers cette rubrique#Installe l’extension pgcrypto.
HStoreExtensionLien vers cette rubrique#Installe l’extension hstore et configure également la connexion afin d’interpréter les données hstore pour un usage possible dans les migrations suivantes.
TrigramExtensionLien vers cette rubrique#Installe l’extension pg_trgm.
UnaccentExtensionLien vers cette rubrique#Installe l’extension unaccent.
Si vous avez besoin de filtrer ou de trier une colonne selon une collation particulière fournie par votre système d’exploitation mais pas par PostgreSQL, vous pouvez gérer les collations de votre base de données avec un fichier de migration. Ces collations peuvent ensuite être référencées dans le paramètre db_collation des champs CharField, TextField et de leurs sous-classes.
Par exemple, pour créer une collation pour le tri des annuaires téléphoniques allemands
\nfrom django.contrib.postgres.operations import CreateCollation\n\n\nclass Migration(migrations.Migration):\n ...\n\n operations = [\n CreateCollation(\n "case_insensitive",\n provider="icu",\n locale="und-u-ks-level2",\n deterministic=False,\n ),\n ...,\n ]\nCrée une collation avec les paramètres name, locale et provider fournis.
Définissez le paramètre deterministic à False pour créer une collation non déterministe, par exemple pour le filtrage non sensible à la casse.
Enlève les collations nommées name.
Lors de l’inversion de la migration, cette opération crée une collation avec les arguments locale, provider et deterministic indiqués. C’est pourquoi locale est obligatoire pour que l’opération puisse être réversible.
PostgreSQL prend en charge l’option CONCURRENTLY pour les instructions CREATE INDEX et DROP INDEX pour ajouter et supprimer des index sans verrouiller les écritures. Cette option est utile pour l’ajout ou la suppression d’index dans une base de données active en production.
Comme AddIndex, mais crée un index avec l’option CONCURRENTLY. Il existe quelques mises en garde à respecter quand on utilise cette option, lisez la documentation PostgreSQL sur la construction concurrente d’index.
Comme RemoveIndex, mais supprime l’index avec l’option CONCURRENTLY. Il existe quelques mises en garde à respecter quand on utilise cette option, lisez la documentation PostgreSQL.
PostgreSQL prend en charge l’option NOT VALID avec l’instruction ADD CONSTRAINT afin d’ajouter des contraintes d’intégrité sans appliquer leur validation sur les lignes existantes. Cette option est pratique si vous souhaitez éviter le parcours potentiellement long de la table pour vérifier si toutes les lignes existantes respectent la contrainte.
Pour valider plus tard les contraintes d’intégrité créées avec l’option NOT VALID, utilisez l’opération ValidateConstraint.
Consultez la documentation PostgreSQL pour plus de détails.
\nComme AddConstraint, mais évite de valider la contrainte pour les lignes existantes.
Parcours la table et valide la contrainte d’intégrité donnée pour les lignes existantes.
\n