From 0bf3fe8f6f089f6023f3917ce8faa050ad0b79b0 Mon Sep 17 00:00:00 2001
From: Mike Bayer <mike_mp@zzzcomputing.com>
Date: Mon, 30 Jan 2012 14:34:37 -0500
Subject: [PATCH] fix docstring references

---
 alembic/migration.py  | 6 +++---
 alembic/operations.py | 4 ++--
 docs/build/api.rst    | 2 +-
 docs/build/ops.rst    | 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/alembic/migration.py b/alembic/migration.py
index 4e86446..d610b3b 100644
--- a/alembic/migration.py
+++ b/alembic/migration.py
@@ -23,11 +23,11 @@ class MigrationContext(object):
 
     The :class:`.MigrationContext` that's established for a 
     duration of a migration command is available via the 
-    :attr:`.EnvironmentContext.migration_context` datamember,
+    :meth:`.EnvironmentContext.get_context` method,
     which is available at ``alembic.context``::
     
         from alembic import context
-        migration_context = context.migration_context
+        migration_context = context.get_context()
     
     A :class:`.MigrationContext` can be created programmatically
     for usage outside of the usual Alembic migrations flow,
@@ -193,7 +193,7 @@ def bind(self):
         in :ref:`sqlexpression_toplevel` as well as 
         for usage with the :meth:`sqlalchemy.schema.Table.create`
         and :meth:`sqlalchemy.schema.MetaData.create_all` methods
-        of :class:`.Table`, :class:`.MetaData`.
+        of :class:`~sqlalchemy.schema.Table`, :class:`~sqlalchemy.schema.MetaData`.
 
         Note that when "standard output" mode is enabled, 
         this bind will be a "mock" connection handler that cannot
diff --git a/alembic/operations.py b/alembic/operations.py
index a3ddfef..1bbe5a1 100644
--- a/alembic/operations.py
+++ b/alembic/operations.py
@@ -122,7 +122,7 @@ def _ensure_table_for_fk(self, metadata, fk):
                 rel_t.append_column(schema.Column(cname, NULLTYPE))
 
     def get_context(self):
-        """Return the :class:`.MigrationsContext` object that's
+        """Return the :class:`.MigrationContext` object that's
         currently in use.
 
         """
@@ -657,7 +657,7 @@ def get_bind(self):
         """Return the current 'bind'.
 
         Under normal circumstances, this is the 
-        :class:`sqlalchemy.engine.Connection` currently being used
+        :class:`~sqlalchemy.engine.base.Connection` currently being used
         to emit SQL to the database.
 
         In a SQL script context, this value is ``None``. [TODO: verify this]
diff --git a/docs/build/api.rst b/docs/build/api.rst
index 73e0948..def71a3 100644
--- a/docs/build/api.rst
+++ b/docs/build/api.rst
@@ -29,7 +29,7 @@ of database dialect in use, are not.   Once the
 is said to be *configured* with database connectivity, available via
 a new :class:`.MigrationContext` object.   The :class:`.MigrationContext`
 is associated with the :class:`.EnvironmentContext` object
-via the :attr:`.EnvironmentContext.migration_context` datamember.
+via the :meth:`.EnvironmentContext.get_context` method.
 
 Finally, ``env.py`` calls upon the :meth:`.EnvironmentContext.run_migrations`
 method.   Within this method, a new :class:`.Operations` object, which
diff --git a/docs/build/ops.rst b/docs/build/ops.rst
index 4322bfb..1df9d27 100644
--- a/docs/build/ops.rst
+++ b/docs/build/ops.rst
@@ -25,7 +25,7 @@ appropriate SQLAlchemy metadata, typically involving
 objects.  This so that migration instructions can be 
 given in terms of just the string names and/or flags involved.   
 The exceptions to this
-rule include the :meth:`~.Operations.add_column` and :func:`~.Operations.create_table`
+rule include the :meth:`~.Operations.add_column` and :meth:`~.Operations.create_table`
 directives, which require full :class:`~sqlalchemy.schema.Column`
 objects, though the table metadata is still generated here.