BaseDatabaseSchemaEditor.create_model(model) [source] Creates a new table in the database for the provided model, along with any unique constraints or indexes it requires.

BaseDatabaseSchemaEditor.alter_unique_together(model, old_unique_together, new_unique_together) [source] Changes a model’s unique_together value; this will add or remove unique constraints from the model’s table until they match the new value.

BaseDatabaseSchemaEditor.alter_index_together(model, old_index_together, new_index_together) [source] Changes a model’s index_together value; this will add or remove indexes from the model’s table until they match the new value.

BaseDatabaseSchemaEditor.alter_field(model, old_field, new_field, strict=False) [source] This transforms the field on the model from the old field to the new one. This includes changing the name of the column (the db_column attribute), changing the type of the field (if the field class changes), changing the NULL status of the field, adding or removing field-only unique constraints and indexes, changing primary key, and changing the destination of ForeignKey constraints. The most common tran

BaseDatabaseSchemaEditor.alter_db_tablespace(model, old_db_tablespace, new_db_tablespace) [source] Moves the model’s table from one tablespace to another.

BaseDatabaseSchemaEditor.alter_db_table(model, old_db_table, new_db_table) [source] Renames the model’s table from old_db_table to new_db_table.

BaseDatabaseSchemaEditor.add_field(model, field) [source] Adds a column (or sometimes multiple) to the model’s table to represent the field. This will also add indexes or a unique constraint if the field has db_index=True or unique=True. If the field is a ManyToManyField without a value for through, instead of creating a column, it will make a table to represent the relationship. If through is provided, it is a no-op. If the field is a ForeignKey, this will also add the foreign key constrain

class BaseDatabaseSchemaEditor [source] Django’s migration system is split into two parts; the logic for calculating and storing what operations should be run (django.db.migrations), and the database abstraction layer that turns things like “create a model” or “delete a field” into SQL - which is the job of the SchemaEditor. It’s unlikely that you will want to interact directly with SchemaEditor as a normal developer using Django, but if you want to write your own migration system, or have m

Django attempts to support as many features as possible on all database backends. However, not all database backends are alike, and we’ve had to make design decisions on which features to support and which assumptions we can make safely. This file describes some of the features that might be relevant to Django usage. Of course, it is not intended as a replacement for server-specific documentation or reference manuals. General notes Persistent connections Persistent connections avoid the overhea

Django’s database layer provides various ways to help developers get the most out of their databases. This document gathers together links to the relevant documentation, and adds various tips, organized under a number of headings that outline the steps to take when attempting to optimize your database usage. Profile first As general programming practice, this goes without saying. Find out what queries you are doing and what they are costing you. You may also want to use an external project like