<commit_before>================
``SchemaEditor``
================

.. module:: django.db.backends.base.schema

.. class:: BaseDatabaseSchemaEditor

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 more advanced needs, it's a lot nicer than writing SQL.

Each database backend in Django supplies its own version of ``SchemaEditor``,
and it's always accessible via the ``connection.schema_editor()`` context
manager::

    with connection.schema_editor() as schema_editor:
        schema_editor.delete_model(MyModel)

It must be used via the context manager as this allows it to manage things
like transactions and deferred SQL (like creating ``ForeignKey`` constraints).

It exposes all possible operations as methods, that should be called in
the order you wish changes to be applied. Some possible operations or types
of change are not possible on all databases - for example, MyISAM does not
support foreign key constraints.

If you are writing or maintaining a third-party database backend for Django,
you will need to provide a ``SchemaEditor`` implementation in order to work with
1.7's migration functionality - however, as long as your database is relatively
standard in its use of SQL and relational design, you should be able to
subclass one of the built-in Django ``SchemaEditor`` classes and tweak the
syntax a little. Also note that there are a few new database features that
migrations will look for: ``can_rollback_ddl``
and ``supports_combined_alters`` are the most important.

Methods
=======

``execute()``
-------------

.. method:: BaseDatabaseSchemaEditor.execute(sql, params=[])

Executes the SQL statement passed in, with parameters if supplied. This
is a wrapper around the normal database cursors that allows capture of the SQL
to a ``.sql`` file if the user wishes.

``create_model()``
------------------

.. method:: BaseDatabaseSchemaEditor.create_model(model)

Creates a new table in the database for the provided model, along with any
unique constraints or indexes it requires.<commit_msg>Fixed outdated notes in SchemaEditor docs.<commit_after>================
``SchemaEditor``
================

.. module:: django.db.backends.base.schema

.. class:: BaseDatabaseSchemaEditor

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 more advanced needs, it's a lot nicer than writing SQL.

Each database backend in Django supplies its own version of ``SchemaEditor``,
and it's always accessible via the ``connection.schema_editor()`` context
manager::

    with connection.schema_editor() as schema_editor:
        schema_editor.delete_model(MyModel)

It must be used via the context manager as this allows it to manage things
like transactions and deferred SQL (like creating ``ForeignKey`` constraints).

It exposes all possible operations as methods, that should be called in
the order you wish changes to be applied. Some possible operations or types
of change are not possible on all databases - for example, MyISAM does not
support foreign key constraints.

If you are writing or maintaining a third-party database backend for Django,
you will need to provide a ``SchemaEditor`` implementation in order to work with
Django's migration functionality - however, as long as your database is
relatively standard in its use of SQL and relational design, you should be able
to subclass one of the built-in Django ``SchemaEditor`` classes and tweak the
syntax a little.

Methods
=======

``execute()``
-------------

.. method:: BaseDatabaseSchemaEditor.execute(sql, params=[])

Executes the SQL statement passed in, with parameters if supplied. This
is a wrapper around the normal database cursors that allows capture of the SQL
to a ``.sql`` file if the user wishes.

``create_model()``
------------------

.. method:: BaseDatabaseSchemaEditor.create_model(model)

Creates a new table in the database for the provided model, along with any
unique constraints or indexes it requires.
{'fraction_non_alphanumeric': 0.09106239460370995, 'fraction_numerical': 0.00042158516020236085, 'mean_word_length': 4.588928150765606, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5738943', 'n_tokens_mistral': 1160, 'n_tokens_neox': 1111, 'n_words': 638}