]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commitdiff
Fix cross references
authorVraj Mohan <r.vrajmohan@gmail.com>
Thu, 14 Nov 2013 20:59:06 +0000 (15:59 -0500)
committerVraj Mohan <r.vrajmohan@gmail.com>
Thu, 14 Nov 2013 22:42:55 +0000 (17:42 -0500)
doc/build/core/pooling.rst
doc/build/core/tutorial.rst
doc/build/orm/extensions/mutable.rst
lib/sqlalchemy/engine/reflection.py
lib/sqlalchemy/orm/query.py

index 83ec0252f2392f3ba9c2fb9835f04d249d8d2f5b..550fb35274a2a0864ef68a6bcc84194471751179 100644 (file)
@@ -291,11 +291,13 @@ API Documentation - Available Pool Implementations
    .. automethod:: connect
    .. automethod:: dispose
    .. automethod:: recreate
+   .. automethod:: unique_connection
 
 .. autoclass:: sqlalchemy.pool.QueuePool
 
-
    .. automethod:: __init__
+   .. automethod:: connect
+   .. automethod:: unique_connection
 
 .. autoclass:: SingletonThreadPool
 
index aa8ba2f2a241ae0bbe95ae51cfa8f78dbcb66f28..492c294cab6a8e8123387d1656193b6ca54b413f 100644 (file)
@@ -238,7 +238,7 @@ we use the ``connect()`` method::
     >>> conn #doctest: +ELLIPSIS
     <sqlalchemy.engine.base.Connection object at 0x...>
 
-The :class:`~sqlalchemy.engine.base.Connection` object represents an actively
+The :class:`~sqlalchemy.engine.Connection` object represents an actively
 checked out DBAPI connection resource. Lets feed it our
 :class:`~sqlalchemy.sql.expression.Insert` object and see what happens:
 
@@ -252,7 +252,7 @@ checked out DBAPI connection resource. Lets feed it our
 So the INSERT statement was now issued to the database. Although we got
 positional "qmark" bind parameters instead of "named" bind parameters in the
 output. How come ? Because when executed, the
-:class:`~sqlalchemy.engine.base.Connection` used the SQLite **dialect** to
+:class:`~sqlalchemy.engine.Connection` used the SQLite **dialect** to
 help generate the statement; when we use the ``str()`` function, the statement
 isn't aware of this dialect, and falls back onto a default which uses named
 parameters. We can view this manually as follows:
@@ -264,9 +264,9 @@ parameters. We can view this manually as follows:
     'INSERT INTO users (name, fullname) VALUES (?, ?)'
 
 What about the ``result`` variable we got when we called ``execute()`` ? As
-the SQLAlchemy :class:`~sqlalchemy.engine.base.Connection` object references a
+the SQLAlchemy :class:`~sqlalchemy.engine.Connection` object references a
 DBAPI connection, the result, known as a
-:class:`~sqlalchemy.engine.result.ResultProxy` object, is analogous to the DBAPI
+:class:`~sqlalchemy.engine.ResultProxy` object, is analogous to the DBAPI
 cursor object. In the case of an INSERT, we can get important information from
 it, such as the primary key values which were generated from our statement:
 
@@ -292,7 +292,7 @@ Our insert example above was intentionally a little drawn out to show some
 various behaviors of expression language constructs. In the usual case, an
 :class:`~sqlalchemy.sql.expression.Insert` statement is usually compiled
 against the parameters sent to the ``execute()`` method on
-:class:`~sqlalchemy.engine.base.Connection`, so that there's no need to use
+:class:`~sqlalchemy.engine.Connection`, so that there's no need to use
 the ``values`` keyword with :class:`~sqlalchemy.sql.expression.Insert`. Lets
 create a generic :class:`~sqlalchemy.sql.expression.Insert` statement again
 and use it in the "normal" way:
@@ -363,10 +363,10 @@ Above, we issued a basic :func:`.select` call, placing the ``users`` table
 within the COLUMNS clause of the select, and then executing. SQLAlchemy
 expanded the ``users`` table into the set of each of its columns, and also
 generated a FROM clause for us. The result returned is again a
-:class:`~sqlalchemy.engine.result.ResultProxy` object, which acts much like a
+:class:`~sqlalchemy.engine.ResultProxy` object, which acts much like a
 DBAPI cursor, including methods such as
-:func:`~sqlalchemy.engine.result.ResultProxy.fetchone` and
-:func:`~sqlalchemy.engine.result.ResultProxy.fetchall`. The easiest way to get
+:func:`~sqlalchemy.engine.ResultProxy.fetchone` and
+:func:`~sqlalchemy.engine.ResultProxy.fetchall`. The easiest way to get
 rows from it is to just iterate:
 
 .. sourcecode:: pycon+sql
@@ -414,7 +414,7 @@ But another way, whose usefulness will become apparent later on, is to use the
 
 Result sets which have pending rows remaining should be explicitly closed
 before discarding. While the cursor and connection resources referenced by the
-:class:`~sqlalchemy.engine.result.ResultProxy` will be respectively closed and
+:class:`~sqlalchemy.engine.ResultProxy` will be respectively closed and
 returned to the connection pool when the object is garbage collected, it's
 better to make it explicit as some database APIs are very picky about such
 things:
index 4b217ca4d767d12d2e46d57799392755b6b0027e..d2a292d905c54d3f212e6a4b9f65760508ddfdfc 100644 (file)
@@ -12,7 +12,6 @@ API Reference
     :members: _parents, coerce
 
 .. autoclass:: Mutable
-     
     :members:
 
 .. autoclass:: MutableComposite
index 461f5eb231f7955a741d37d4428a2dbe026b994c..1f219e30c1efdea9cfe60f97984a856998568363 100644 (file)
@@ -161,7 +161,7 @@ class Inspector(object):
         """Return all table names in referred to within a particular schema.
 
         The names are expected to be real tables only, not views.
-        Views are instead returned using the :meth:`.get_view_names`
+        Views are instead returned using the :meth:`.Inspector.get_view_names`
         method.
 
 
index 9051c081e7950a0d3f0a9dafe9186c75a01a96e5..0b8a100f12f0a4711288e95fd08953a75c9102a6 100644 (file)
@@ -541,7 +541,7 @@ class Query(object):
         :class:`.Query`, converted
         to a scalar subquery with a label of the given name.
 
-        Analogous to :meth:`sqlalchemy.sql.SelectBaseMixin.label`.
+        Analogous to :meth:`sqlalchemy.sql.expression.SelectBase.label`.
 
         .. versionadded:: 0.6.5
 
@@ -553,7 +553,7 @@ class Query(object):
         """Return the full SELECT statement represented by this
         :class:`.Query`, converted to a scalar subquery.
 
-        Analogous to :meth:`sqlalchemy.sql.SelectBaseMixin.as_scalar`.
+        Analogous to :meth:`sqlalchemy.sql.expression.SelectBase.as_scalar`.
 
         .. versionadded:: 0.6.5