Tindakan perpindahan basisdata¶
Semua operations ini tersedia dari modul django.contrib.postgres.operations
.
Membuat tambahan menggunakan perpindahan¶
Anda dapat membuat tambahan PostgreSQL dalam basisdata anda menggunakan berkas pemindahan. Contoh ini membuat sebuah tambahan hstore, tetapi prinsip-prinsip sama berlaku untuk tambahan-tambahan lain.
Setel tambahan hstore dalam PostgreSQL sebelum tindakan pertama CreateModel
atau AddField
yang melibatkan HStoreField
dengan menambahkan perpindahan dengan tindakan HStoreExtension
. Sebagai contoh:
from django.contrib.postgres.operations import HStoreExtension
class Migration(migrations.Migration):
...
operations = [HStoreExtension(), ...]
The operation skips adding the extension if it already exists.
For most extensions, this requires a database user with superuser privileges.
If the Django database user doesn't have the appropriate privileges, you'll
have to create the extension outside of Django migrations with a user that has
them. In that case, connect to your Django database and run the query
CREATE EXTENSION IF NOT EXISTS hstore;
.
CreateExtension
¶
HStoreExtension
¶
-
class
HStoreExtension
¶ Pasang tambahan
hstore
dan juga setel hubungan pada penterjemah data hstore untuk kemungkinan penggunaan dalam perpindahaan selanjutnya.
Managing collations using migrations¶
If you need to filter or order a column using a particular collation that your
operating system provides but PostgreSQL does not, you can manage collations in
your database using a migration file. These collations can then be used with
the db_collation
parameter on CharField
,
TextField
, and their subclasses.
For example, to create a collation for German phone book ordering:
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)¶ Creates a collation with the given
name
,locale
andprovider
.Set the
deterministic
parameter toFalse
to create a non-deterministic collation, such as for case-insensitive filtering.
-
class
RemoveCollation
(name, locale, *, provider='libc', deterministic=True)¶ Removes the collations named
name
.When reversed this is creating a collation with the provided
locale
,provider
, anddeterministic
arguments. Therefore,locale
is required to make this operation reversible.
Concurrent index operations¶
PostgreSQL supports the CONCURRENTLY
option to CREATE INDEX
and
DROP INDEX
statements to add and remove indexes without locking out writes.
This option is useful for adding or removing an index in a live production
database.
-
class
AddIndexConcurrently
(model_name, index)¶ Like
AddIndex
, but creates an index with theCONCURRENTLY
option. This has a few caveats to be aware of when using this option, see the PostgreSQL documentation of building indexes concurrently.
-
class
RemoveIndexConcurrently
(model_name, name)¶ Like
RemoveIndex
, but removes the index with theCONCURRENTLY
option. This has a few caveats to be aware of when using this option, see the PostgreSQL documentation.
Catatan
The CONCURRENTLY
option is not supported inside a transaction (see
non-atomic migration).
Adding constraints without enforcing validation¶
PostgreSQL supports the NOT VALID
option with the ADD CONSTRAINT
statement to add check constraints without enforcing validation on existing
rows. This option is useful if you want to skip the potentially lengthy scan of
the table to verify that all existing rows satisfy the constraint.
To validate check constraints created with the NOT VALID
option at a later
point of time, use the
ValidateConstraint
operation.
See the PostgreSQL documentation for more details.
-
class
AddConstraintNotValid
(model_name, constraint)¶ Like
AddConstraint
, but avoids validating the constraint on existing rows.
-
class
ValidateConstraint
(model_name, name)¶ Scans through the table and validates the given check constraint on existing rows.
Catatan
AddConstraintNotValid
and ValidateConstraint
operations should be
performed in two separate migrations. Performing both operations in the
same atomic migration has the same effect as
AddConstraint
, whereas performing
them in a single non-atomic migration, may leave your database in an
inconsistent state if the ValidateConstraint
operation fails.