summaryrefslogtreecommitdiff
path: root/doc/build/orm
diff options
context:
space:
mode:
Diffstat (limited to 'doc/build/orm')
-rw-r--r--doc/build/orm/internals.rst3
-rw-r--r--doc/build/orm/persistence_techniques.rst11
-rw-r--r--doc/build/orm/queryguide/api.rst6
-rw-r--r--doc/build/orm/queryguide/queryguide_nav_include.rst3
-rw-r--r--doc/build/orm/queryguide/relationships.rst12
-rw-r--r--doc/build/orm/session_events.rst7
6 files changed, 0 insertions, 42 deletions
diff --git a/doc/build/orm/internals.rst b/doc/build/orm/internals.rst
index 529baf1d1..a6ffa663f 100644
--- a/doc/build/orm/internals.rst
+++ b/doc/build/orm/internals.rst
@@ -22,9 +22,6 @@ sections, are listed here.
.. autoclass:: Composite
-.. .. autoclass:: CompositeProperty
- .. :members:
-
.. autoclass:: AttributeEventToken
:members:
diff --git a/doc/build/orm/persistence_techniques.rst b/doc/build/orm/persistence_techniques.rst
index d28965bf9..61bdbcbab 100644
--- a/doc/build/orm/persistence_techniques.rst
+++ b/doc/build/orm/persistence_techniques.rst
@@ -831,14 +831,3 @@ ORM extension. An example of use is at: ref_examples_sharding.
.. _bulk_operations:
-Bulk Operations
-===============
-
-.. legacy::
-
- SQLAlchemy 2.0 has integrated the :class:`_orm.Session` "bulk insert" and
- "bulk update" capabilities into 2.0 style :meth:`_orm.Session.execute`
- method, making direct use of :class:`_dml.Insert` and :class:`_dml.Update`
- constructs. See the document at :doc:`queryguide/dml` for documentation,
- including :ref:`orm_queryguide_legacy_bulk_insert` which illustrates migration
- from the older methods to the new methods.
diff --git a/doc/build/orm/queryguide/api.rst b/doc/build/orm/queryguide/api.rst
index a5b155447..38e5a3a79 100644
--- a/doc/build/orm/queryguide/api.rst
+++ b/doc/build/orm/queryguide/api.rst
@@ -287,12 +287,6 @@ Identity Token
.. doctest-disable:
-.. deepalchemy:: This option is an advanced-use feature mostly intended
- to be used with the ref_horizontal_sharding_toplevel extension. For
- typical cases of loading objects with identical primary keys from different
- "shards" or partitions, consider using individual :class:`_orm.Session`
- objects per shard first.
-
The "identity token" is an arbitrary value that can be associated within
the :term:`identity key` of newly loaded objects. This element exists
diff --git a/doc/build/orm/queryguide/queryguide_nav_include.rst b/doc/build/orm/queryguide/queryguide_nav_include.rst
index a86002164..0534c3e7e 100644
--- a/doc/build/orm/queryguide/queryguide_nav_include.rst
+++ b/doc/build/orm/queryguide/queryguide_nav_include.rst
@@ -8,7 +8,4 @@
Previous: |prev| | Next: |next|
-.. footer_topic:: |tutorial_title|
-
- Next Query Guide Section: |next|
diff --git a/doc/build/orm/queryguide/relationships.rst b/doc/build/orm/queryguide/relationships.rst
index 70f9d318c..5665264a1 100644
--- a/doc/build/orm/queryguide/relationships.rst
+++ b/doc/build/orm/queryguide/relationships.rst
@@ -850,18 +850,6 @@ Things to know about this kind of loading include:
Subquery Eager Loading
----------------------
-.. legacy:: The :func:`_orm.subqueryload` eager loader is mostly legacy
- at this point, superseded by the :func:`_orm.selectinload` strategy
- which is of much simpler design, more flexible with features such as
- :ref:`Yield Per <orm_queryguide_yield_per>`, and emits more efficient SQL
- statements in most cases. As :func:`_orm.subqueryload` relies upon
- re-interpreting the original SELECT statement, it may fail to work
- efficiently when given very complex source queries.
-
- :func:`_orm.subqueryload` may continue to be useful for the specific
- case of an eager loaded collection for objects that use composite primary
- keys, on the Microsoft SQL Server backend that continues to not have
- support for the "tuple IN" syntax.
Subquery loading is similar in operation to selectin eager loading, however
the SELECT statement which is emitted is derived from the original statement,
diff --git a/doc/build/orm/session_events.rst b/doc/build/orm/session_events.rst
index 584a3402e..d98be69f5 100644
--- a/doc/build/orm/session_events.rst
+++ b/doc/build/orm/session_events.rst
@@ -168,13 +168,6 @@ to intercept all objects that extend from ``HasTimestamp`` and filter their
Re-Executing Statements
^^^^^^^^^^^^^^^^^^^^^^^
-.. deepalchemy:: the statement re-execution feature involves a slightly
- intricate recursive sequence, and is intended to solve the fairly hard
- problem of being able to re-route the execution of a SQL statement into
- various non-SQL contexts. The twin examples of "dogpile caching" and
- "horizontal sharding", linked below, should be used as a guide for when this
- rather advanced feature is appropriate to be used.
-
The :class:`_orm.ORMExecuteState` is capable of controlling the execution of
the given statement; this includes the ability to either not invoke the
statement at all, allowing a pre-constructed result set retrieved from a cache to