ÿØÿàJFIFÿþ ÿÛC       ÿÛC ÿÀÿÄÿÄ"#QrÿÄÿÄ&1!A"2qQaáÿÚ ?Øy,æ/3JæݹÈ߲؋5êXw²±ÉyˆR”¾I0ó2—PI¾IÌÚiMö¯–þrìN&"KgX:Šíµ•nTJnLK„…@!‰-ý ùúmë;ºgµŒ&ó±hw’¯Õ@”Ü— 9ñ-ë.²1<yà‚¹ïQÐU„ہ?.’¦èûbß±©Ö«Âw*VŒ) `$‰bØԟ’ëXÖ-ËTÜíGÚ3ð«g Ÿ§¯—Jx„–’U/ÂÅv_s(Hÿ@TñJÑãõçn­‚!ÈgfbÓc­:él[ðQe 9ÀPLbÃãCµm[5¿ç'ªjglå‡Ûí_§Úõl-;"PkÞÞÁQâ¼_Ñ^¢SŸx?"¸¦ùY騐ÒOÈ q’`~~ÚtËU¹CڒêV  I1Áß_ÿÙ.. _alembic.runtime.environment.toplevel: ======================= Runtime Objects ======================= The "runtime" of Alembic involves the :class:`.EnvironmentContext` and :class:`.MigrationContext` objects. These are the objects that are in play once the ``env.py`` script is loaded up by a command and a migration operation proceeds. The Environment Context ======================= The :class:`.EnvironmentContext` class provides most of the API used within an ``env.py`` script. Within ``env.py``, the instantated :class:`.EnvironmentContext` is made available via a special *proxy module* called ``alembic.context``. That is, you can import ``alembic.context`` like a regular Python module, and each name you call upon it is ultimately routed towards the current :class:`.EnvironmentContext` in use. In particular, the key method used within ``env.py`` is :meth:`.EnvironmentContext.configure`, which establishes all the details about how the database will be accessed. .. automodule:: alembic.runtime.environment :members: EnvironmentContext .. _alembic.runtime.migration.toplevel: The Migration Context ===================== The :class:`.MigrationContext` handles the actual work to be performed against a database backend as migration operations proceed. It is generally not exposed to the end-user. .. automodule:: alembic.runtime.migration :members: MigrationContext