Current File : //opt/alt/python37/share/doc/alt-python37-alembic-0.8.3/docs/build/api/overview.rst
========
Overview
========
.. note:: this section is a technical overview of the
**internal API of Alembic**.
This section is only useful for developers who wish to extend the
capabilities of Alembic; for regular users, reading this section
is **not necessary**.
A visualization of the primary features of Alembic's internals is presented
in the following figure. The module and class boxes do not list out
all the operations provided by each unit; only a small set of representative
elements intended to convey the primary purpose of each system.
.. image:: api_overview.png
The script runner for Alembic is present in the :ref:`alembic.config.toplevel` module.
This module produces a :class:`.Config` object and passes it to the
appropriate function in :ref:`alembic.command.toplevel`. Functions within
:ref:`alembic.command.toplevel` will typically instantiate an
:class:`.ScriptDirectory` instance, which represents the collection of
version files, and an :class:`.EnvironmentContext`, which is a configurational
facade passed to the environment's ``env.py`` script.
The :class:`.EnvironmentContext` object is the primary object used within
the ``env.py`` script, whose main purpose is that of a facade for creating and using
a :class:`.MigrationContext` object, which is the actual migration engine
that refers to a database implementation. The primary method called
on this object within an ``env.py`` script is the
:meth:`.EnvironmentContext.configure` method, which sets up the
:class:`.MigrationContext` with database connectivity and behavioral
configuration. It also supplies methods for transaction demarcation and
migration running, but these methods ultimately call upon the
:class:`.MigrationContext` that's been configured.
:class:`.MigrationContext` is the gateway to the database
for other parts of the application, and produces a :class:`.DefaultImpl`
object which does the actual database communication, and knows how to
create the specific SQL text of the various DDL directives such as
ALTER TABLE; :class:`.DefaultImpl` has subclasses that are per-database-backend.
In "offline" mode (e.g. ``--sql``), the :class:`.MigrationContext` will
produce SQL to a file output stream instead of a database.
During an upgrade or downgrade operation, a specific series of migration
scripts are invoked starting with the :class:`.MigrationContext` in conjunction
with the :class:`.ScriptDirectory`; the actual scripts themselves make use
of the :class:`.Operations` object, which provide the end-user interface to
specific database operations. The :class:`.Operations` object is generated
based on a series of "operation directive" objects that are user-extensible,
and start out in the :ref:`alembic.operations.ops.toplevel` module.
Another prominent feature of Alembic is the "autogenerate" feature, which
produces new migration scripts that contain Python code. The autogenerate
feature starts in :ref:`alembic.autogenerate.toplevel`, and is used exclusively
by the :func:`.alembic.command.revision` command when the ``--autogenerate``
flag is passed. Autogenerate refers to the :class:`.MigrationContext`
and :class:`.DefaultImpl` in order to access database connectivity and
access per-backend rules for autogenerate comparisons. It also makes use
of :ref:`alembic.operations.ops.toplevel` in order to represent the operations that
it will render into scripts.
Mini Shell