# Documentation Django 5.2.8

# 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;`.

## `CreateExtension`

class CreateExtension(name, hints=None)

  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.

  name

    Ce paramètre est obligatoire. Le nom de l’extension à installer.

  hints
    New in Django 6.0.

    The optional `hints` argument will be passed as `**hints` to the `allow_migrate()` method of database routers to assist them in making routing decisions.

## `BloomExtension`

class BloomExtension(hints=None)

  Installe l’extension `bloom`.

  hints
    New in Django 6.0.

    The optional `hints` argument will be passed as `**hints` to the `allow_migrate()` method of database routers to assist them in making routing decisions.

## `BtreeGinExtension`

class BtreeGinExtension(hints=None)

  Installe l’extension `btree_gin`.

  hints
    New in Django 6.0.

    The optional `hints` argument will be passed as `**hints` to the `allow_migrate()` method of database routers to assist them in making routing decisions.

## `BtreeGistExtension`

class BtreeGistExtension(hints=None)

  Installe l’extension `btree_gist`.

  hints
    New in Django 6.0.

    The optional `hints` argument will be passed as `**hints` to the `allow_migrate()` method of database routers to assist them in making routing decisions.

## `CITextExtension`

class CITextExtension(hints=None)

  Installe l’extension `citext`.

  hints
    New in Django 6.0.

    The optional `hints` argument will be passed as `**hints` to the `allow_migrate()` method of database routers to assist them in making routing decisions.

## `CryptoExtension`

class CryptoExtension(hints=None)

  Installe l’extension `pgcrypto`.

  hints
    New in Django 6.0.

    The optional `hints` argument will be passed as `**hints` to the `allow_migrate()` method of database routers to assist them in making routing decisions.

## `HStoreExtension`

class HStoreExtension(hints=None)

  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.

  hints
    New in Django 6.0.

    The optional `hints` argument will be passed as `**hints` to the `allow_migrate()` method of database routers to assist them in making routing decisions.

## `TrigramExtension`

class TrigramExtension(hints=None)

  Installe l’extension `pg_trgm`.

  hints
    New in Django 6.0.

    The optional `hints` argument will be passed as `**hints` to the `allow_migrate()` method of database routers to assist them in making routing decisions.

## `UnaccentExtension`

class UnaccentExtension(hints=None)

  Installe l’extension `unaccent`.

  hints
    New in Django 6.0.

    The optional `hints` argument will be passed as `**hints` to the `allow_migrate()` method of database routers to assist them in making routing decisions.

## 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(
                "case_insensitive",
                provider="icu",
                locale="und-u-ks-level2",
                deterministic=False,
            ),
            ...,
        ]

class CreateCollation(name, locale, *, provider='libc', deterministic=True)

  Cré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.

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` et `deterministic` indiqués. C’est pourquoi `locale` est obligatoire pour que l’opération puisse être réversible.

## 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’option `CONCURRENTLY`. 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’option `CONCURRENTLY`. 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).

## Ajout de contraintes sans appliquer la validation

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.

class AddConstraintNotValid(model_name, constraint)

  Comme `AddConstraint`, mais évite de valider la contrainte pour les lignes existantes.

class ValidateConstraint(model_name, name)

  Parcours la table et valide la contrainte d’intégrité donnée pour les lignes existantes.

Note

Les opérations `AddConstraintNotValid` et `ValidateConstraint` doivent être appliquées dans deux migrations séparées. Si vous appliquez les deux opérations dans la même migration atomique, l’effet est le même que si vous utilisiez `AddConstraint`, alors que si vous les appliquez les deux dans une seule migration non atomique, le risque est de laisser votre base de données dans un état incohérent dans le cas où l’opération `ValidateConstraint` échoue.