Opérations de migration de base de données¶
Toutes ces opérations sont disponibles dans le module django.contrib.postgres.operations
.
Création d’extension à l’aide des migrations¶
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.
Configurer 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
class Migration(migrations.Migration):
...
operations = [
HStoreExtension(),
...
]
L’opération omet l’ajout de l’extension si celle-ci existe déjà.
Pour 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;
.
Dans les anciennes versions, on ne contrôlait pas la préexistence de l’extension.
CreateExtension
¶
HStoreExtension
¶
-
class
HStoreExtension
¶ 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.
Gestion des collations à l’aide des migrations¶
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
from django.contrib.postgres.operations import CreateCollation
class Migration(migrations.Migration):
...
operations = [
CreateCollation(
'german_phonebook',
provider='icu',
locale='und-u-ks-level2',
),
...
]
-
class
CreateCollation
(name, locale, *, provider='libc', deterministic=True)¶ Crée une collation avec les paramètres
name
,locale
etprovider
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.
-
class
RemoveCollation
(name, locale, *, provider='libc', deterministic=True)¶ 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
etdeterministic
indiqués. C’est pourquoilocale
est obligatoire pour que l’opération puisse être réversible.
Restrictions
PostgreSQL 9.6 ne prend en charge que le fournisseur (provider
) 'libc'
.
Les collations non déterministes ne sont prises en charge qu’à partir de PostgreSQL 12+.
Opérations d’index concurrentes¶
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.
-
class
AddIndexConcurrently
(model_name, index)¶ Comme
AddIndex
, mais crée un index avec l’optionCONCURRENTLY
. Il existe quelques mises en garde à respecter quand on utilise cette option, lisez la documentation PostgreSQL sur la construction concurrente d’index.
-
class
RemoveIndexConcurrently
(model_name, name)¶ Comme
RemoveIndex
, mais supprime l’index avec l’optionCONCURRENTLY
. Il existe quelques mises en garde à respecter quand on utilise cette option, lisez la documentation PostgreSQL.
Note
L’option CONCURRENTLY
n’est pas prise en charge à l’intérieur d’une transaction (voir migrations non atomiques).