# Django 5.2.8 documentation

# Migrering av databaser

Alla dessa operationer är tillgängliga från modulen `django.contrib.postgres.operations`.

## Skapa tillägg med hjälp av migreringar

Du kan skapa ett PostgreSQL-tillägg i din databas med hjälp av en migreringsfil. Detta exempel skapar en hstore-förlängning, men samma principer gäller för andra tillägg.

Ställ in hstore-tillägget i PostgreSQL före den första `CreateModel` eller `AddField` -operationen som involverar `HStoreField` genom att lägga till en migrering med `HStoreExtension` -operationen. Till exempel:

    from django.contrib.postgres.operations import HStoreExtension

    class Migration(migrations.Migration):
        ...

        operations = [HStoreExtension(), ...]

Operationen hoppar över att lägga till tillägget om det redan finns.

För de flesta tillägg kräver detta en databasanvändare med superanvändarrättigheter. Om Django-databasanvändaren inte har lämpliga privilegier måste du skapa tillägget utanför Django-migreringar med en användare som har dem. I så fall ansluter du till din Django-databas och kör frågan `CREATE EXTENSION IF NOT EXISTS hstore;`.

## `CreateExtension`

class CreateExtension(name, hints=None)

  En `` Operation `` underklass som installerar en PostgreSQL-förlängning. För vanliga tillägg, använd en av de mer specifika underklasserna nedan.

  name

    Detta är ett obligatoriskt argument. Namnet på det tillägg som ska installeras.

  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)

  Installerar tillägget `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)

  Installerar tillägget `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)

  Installerar tillägget `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)

  Installerar tillägget `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)

  Installerar tillägget `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)

  Installerar tillägget `hstore` och konfigurerar även anslutningen för att tolka hstore-data för eventuell användning i efterföljande migreringar.

  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)

  Installerar tillägget `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)

  Installerar tillägget `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.

## Hantera kollationer med hjälp av migreringar

Om du behöver filtrera eller beställa en kolumn med en viss kollationering som ditt operativsystem tillhandahåller men PostgreSQL inte gör det, kan du hantera kollationer i din databas med hjälp av en migreringsfil. Dessa kollationer kan sedan användas med parametern `db_collation` på `CharField`, `TextField`, och deras underklasser.

Till exempel:, för att skapa en kollationering för tysk telefonkatalogbeställning:

    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)

  Skapar en kollationering med de angivna `name`, `locale` och `provider`.

  Sätt parametern `deterministic` till `False` för att skapa en icke-deterministisk kollationering, t.ex. för skiftlägesokänslig filtrering.

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

  Tar bort de kollationer som heter `namn`.

  När den reverseras skapar detta en kollationering med de angivna argumenten `locale`, `provider` och `deterministic`. Därför krävs `locale` för att göra denna operation reversibel.

## Samtidiga indexoperationer

PostgreSQL stöder alternativet `CONCURRENTLY` till `CREATE INDEX` och `DROP INDEX` uttalanden för att lägga till och ta bort index utan att låsa ut skrivningar. Det här alternativet är användbart för att lägga till eller ta bort ett index i en live produktionsdatabas.

class AddIndexConcurrently(model_name, index)

  Som `AddIndex`, men skapar ett index med alternativet `CONCURRENTLY`. Detta har några försiktighetsåtgärder att vara medveten om när du använder det här alternativet, se `` PostgreSQL-dokumentationen för att bygga index samtidigt <https://www.postgresql.org/docs/current/ sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY>`_.

class RemoveIndexConcurrently(model_name, name)

  Som `RemoveIndex`, men tar bort indexet med alternativet `CONCURRENTLY`. Detta har några varningar att vara medvetna om när du använder det här alternativet, se PostgreSQL-dokumentationen.

Observera

Alternativet `CONCURRENTLY` stöds inte inom en transaktion (se non-atomic migration <non-atomic-migrations>`).

## Lägga till begränsningar utan att tvinga fram validering

PostgreSQL stöder alternativet `` INOT VALID`` med uttalandet `` ADD CONSTRAINT`` för att lägga till kontrollbegränsningar utan att genomdriva validering på befintliga rader. Det här alternativet är användbart om du vill hoppa över den potentiellt långa genomsökningen av tabellen för att verifiera att alla befintliga rader uppfyller begränsningen.

Om du vill validera kontrollbegränsningar som skapats med alternativet `NOT VALID` vid en senare tidpunkt använder du operationen `ValidateConstraint`.

Se ”PostgreSQL-dokumentationen <https://www.postgresql.org/docs/current/ sql-altertable.html#SQL-ALTERTABLE-NOTES>`__ för mer information.

class AddConstraintNotValid(model_name, constraint)

  Som `AddConstraint`, men undviker att validera begränsningen på befintliga rader.

class ValidateConstraint(model_name, name)

  Skannar igenom tabellen och validerar den angivna kontrollbegränsningen på befintliga rader.

Observera

operationerna `AddConstraintNotValid` och `ValidateConstraint` bör utföras i två separata migreringar. Att utföra båda operationerna i samma atomiska migrering har samma effekt som `AddConstraint`, medan att utföra dem i en enda icke-atomisk migrering kan lämna din databas i ett inkonsekvent tillstånd om operationen `ValidateConstraint` misslyckas.