SchemaEditorLink para este cabeçalho#Django’s migration system is split into two parts; the logic for calculating\nand storing what operations should be run (django.db.migrations), and the\ndatabase abstraction layer that turns things like “create a model” or\n“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\na normal developer using Django, but if you want to write your own migration\nsystem, or have more advanced needs, it’s a lot nicer than writing SQL.
Each database backend in Django supplies its own version of SchemaEditor,\nand it’s always accessible via the connection.schema_editor() context\nmanager:
with connection.schema_editor() as schema_editor:\n schema_editor.delete_model(MyModel)\nIt must be used via the context manager as this allows it to manage things\nlike transactions and deferred SQL (like creating ForeignKey constraints).
It exposes all possible operations as methods, that should be called in\nthe order you wish changes to be applied. Some possible operations or types\nof change are not possible on all databases - for example, MyISAM does not\nsupport foreign key constraints.
\nIf you are writing or maintaining a third-party database backend for Django,\nyou will need to provide a SchemaEditor implementation in order to work with\n1.7’s migration functionality - however, as long as your database is relatively\nstandard in its use of SQL and relational design, you should be able to\nsubclass one of the built-in Django SchemaEditor classes and just tweak the\nsyntax a little. Also note that there are a few new database features that\nmigrations will look for: can_rollback_ddl and\nsupports_combined_alters are the most important.
execute()Link para este cabeçalho#Executes the SQL statement passed in, with parameters if supplied. This\nis a simple wrapper around the normal database cursors that allows\ncapture of the SQL to a .sql file if the user wishes.
create_model()Link para este cabeçalho#Creates a new table in the database for the provided model, along with any\nunique constraints or indexes it requires.
\ndelete_model()Link para este cabeçalho#Drops the model’s table in the database along with any unique constraints\nor indexes it has.
\nalter_unique_together()Link para este cabeçalho#Changes a model’s unique_together value; this\nwill add or remove unique constraints from the model’s table until they match\nthe new value.
alter_index_together()Link para este cabeçalho#Changes a model’s index_together value; this\nwill add or remove indexes from the model’s table until they match the new\nvalue.
alter_db_table()Link para este cabeçalho#Renames the model’s table from old_db_table to new_db_table.
alter_db_tablespace()Link para este cabeçalho#Moves the model’s table from one tablespace to another.
\nadd_field()Link para este cabeçalho#Adds a column (or sometimes multiple) to the model’s table to represent the\nfield. This will also add indexes or a unique constraint\nif the field has db_index=True or unique=True.
If the field is a ManyToManyField without a value for through, instead\nof creating a column, it will make a table to represent the relationship. If\nthrough is provided, it is a no-op.
If the field is a ForeignKey, this will also add the foreign key\nconstraint to the column.
remove_field()Link para este cabeçalho#Removes the column(s) representing the field from the model’s table, along\nwith any unique constraints, foreign key constraints, or indexes caused by\nthat field.
\nIf the field is a ManyToManyField without a value for through, it will\nremove the table created to track the relationship. If\nthrough is provided, it is a no-op.
alter_field()Link para este cabeçalho#This transforms the field on the model from the old field to the new one. This\nincludes changing the name of the column (the\ndb_column attribute), changing the type of the\nfield (if the field class changes), changing the NULL status of the field,\nadding or removing field-only unique constraints and indexes, changing primary\nkey, and changing the destination of ForeignKey constraints.
The most common transformation this cannot do is transforming a\nManyToManyField into a normal Field or vice-versa; Django cannot do this\nwithout losing data, and so it will refuse to do it. Instead,\nremove_field() and add_field() should be called separately.
If the database has the supports_combined_alters, Django will try and\ndo as many of these in a single database call as possible; otherwise, it will\nissue a separate ALTER statement for each change, but will not issue ALTERs\nwhere no change is required (as South often did).
All attributes should be considered read-only unless stated otherwise.
\nconnectionLink para este cabeçalho#A connection object to the database. A useful attribute of the connection is\nalias which can be used to determine the name of the database being\naccessed.
This is useful when doing data migrations for migrations with multiple\ndatabases.
\n