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.delete_model(model) [source] Drops the model’s table in the database along with any unique constraints or indexes it has.

BaseDatabaseSchemaEditor.execute(sql, params=[]) [source] Executes the SQL statement passed in, with parameters if supplied. This is a simple wrapper around the normal database cursors that allows capture of the SQL to a .sql file if the user wishes.

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

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

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

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

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