0x1998 - MANAGER

Düzenlenen Dosya: overview.txt

======== 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.
geri dön