- some doc reorg

- change engine.Connection to _connection_cls so sphinx doesn't get upset
- globally add "." to all :class:`Foo`
- start naming sections that are mostly docstrings "API Documentation - blah blah"
- move some ad-hoc docstrings into "API" sections, there is some inconsistency here
and it may be that we just have to leave it that way
- add "internals" rsts to core, orm, I'm not super thrilled how these look but they are
targeted by some of the public api docs, users typically become aware of these anyway

1 files changed, 7 insertions, 7 deletions

diff --git a/lib/sqlalchemy/ext/declarative.py b/lib/sqlalchemy/ext/declarative.py
index e521ddbbf..8ea76d759 100755
--- a/lib/sqlalchemy/ext/declarative.py
+++ b/lib/sqlalchemy/ext/declarative.py
@@ -211,7 +211,7 @@ class declaration can be referenced directly::
             firstname + " " + lastname
         )
 
-Correlated subqueries reference the :class:`Column` objects they
+Correlated subqueries reference the :class:`.Column` objects they
 need either from the local class definition or from remote 
 classes::
 
@@ -483,7 +483,7 @@ a base class and have all the other classes subclass this class.
 
 When using :mod:`~sqlalchemy.ext.declarative`, this need is met by
 using a "mixin class". A mixin class is one that isn't mapped to a
-table and doesn't subclass the declarative :class:`Base`. For example::
+table and doesn't subclass the declarative :class:`.Base`. For example::
 
     class MyMixin(object):
 
@@ -529,14 +529,14 @@ and ``b.c.id`` are two distinct Python objects, referencing their
 parent tables ``a`` and ``b`` respectively.
 
 In the case of the mixin column, it seems that only one
-:class:`Column` object is explicitly created, yet the ultimate 
+:class:`.Column` object is explicitly created, yet the ultimate 
 ``created_at`` column above must exist as a distinct Python object
 for each separate destination class.  To accomplish this, the declarative
-extension creates a **copy** of each :class:`Column` object encountered on 
+extension creates a **copy** of each :class:`.Column` object encountered on 
 a class that is detected as a mixin.
 
 This copy mechanism is limited to simple columns that have no foreign
-keys, as a :class:`ForeignKey` itself contains references to columns
+keys, as a :class:`.ForeignKey` itself contains references to columns
 which can't be properly recreated at this level.  For columns that 
 have foreign keys, as well as for the variety of mapper-level constructs
 that require destination-explicit context, the
@@ -557,7 +557,7 @@ patterns common to many classes can be defined as callables::
 
 Where above, the ``address_id`` class-level callable is executed at the 
 point at which the ``User`` class is constructed, and the declarative
-extension can use the resulting :class:`Column` object as returned by
+extension can use the resulting :class:`.Column` object as returned by
 the method without the need to copy it.
 
 Columns generated by :func:`~.declared_attr` can also be
@@ -1406,7 +1406,7 @@ def declarative_base(bind=None, metadata=None, mapper=None, cls=object,
       cls.__init__ by way of the normal Python semantics.
 
     :param metaclass:
-      Defaults to :class:`DeclarativeMeta`.  A metaclass or __metaclass__
+      Defaults to :class:`.DeclarativeMeta`.  A metaclass or __metaclass__
       compatible callable to use as the meta type of the generated
       declarative base class.