diff options
Diffstat (limited to 'doc/build')
35 files changed, 491 insertions, 220 deletions
diff --git a/doc/build/changelog/README.txt b/doc/build/changelog/README.txt new file mode 100644 index 000000000..65ee529dd --- /dev/null +++ b/doc/build/changelog/README.txt @@ -0,0 +1,34 @@ +Individual per-changelog files are placed into their corresponding release's +directory (for example: changelog files for the `1.4` branch are placed in the +`./unreleased_14/` directory, such as `./unreleased_14/4710.rst`). + +Files are in `.rst` format, which are pulled in by +changelog (https://github.com/sqlalchemyorg/changelog; version 0.4.0 or higher) +to be rendered into their corresponding `changelog_xx.rst` file +(for example: `./changelog_14.rst`). At release time, the files in the +`unreleased_xx/` directory are removed and written directly into the changelog. + +Rationale is so that multiple changes being merged into Gerrit don't produce +conflicts. Note that Gerrit does not support alternate merge handlers unlike +git itself (and the alternate merge handlers don't work that well either). + +Each changelog file should be named `{ID}.rst`, wherein `ID` is the unique +identifier of the issue in the Github issue tracker. + +In the example below, the `tags` and `tickets` contain a comma-separated listing +because there are more than one element. + +================================================================================ + Example Below +================================================================================ + + +.. change:: + :tags: bug, sql, orm + :tickets: 4839, 3257 + + Please use reStructuredText and Sphinx markup when possible. For example + method :meth:`.Index.create` and parameter + :paramref:`.Index.create.checkfirst`, and :class:`.Table` which will + subject to the relevant markup. Also please note the indentions required + for the text. diff --git a/doc/build/changelog/changelog_07.rst b/doc/build/changelog/changelog_07.rst index f921d2949..43ae2fe0d 100644 --- a/doc/build/changelog/changelog_07.rst +++ b/doc/build/changelog/changelog_07.rst @@ -2578,7 +2578,7 @@ The behavior of =/!= when comparing a scalar select to a value will no longer produce IN/NOT IN as of 0.8; - this behavior is a little too heavy handed (use in_() if + this behavior is a little too heavy handed (use ``in_()`` if you want to emit IN) and now emits a deprecation warning. To get the 0.8 behavior immediately and remove the warning, a compiler recipe is given at diff --git a/doc/build/changelog/changelog_08.rst b/doc/build/changelog/changelog_08.rst index 90407b2b2..7e0994dfc 100644 --- a/doc/build/changelog/changelog_08.rst +++ b/doc/build/changelog/changelog_08.rst @@ -356,9 +356,9 @@ :tickets: 2957 :versions: 0.9.3 - Fixed bug where :meth:`.in_()` would go into an endless loop if - erroneously passed a column expression whose comparator included - the ``__getitem__()`` method, such as a column that uses the + Fixed bug where :meth:`.ColumnOperators.in_()` would go into an endless + loop if erroneously passed a column expression whose comparator + included the ``__getitem__()`` method, such as a column that uses the :class:`.postgresql.ARRAY` type. .. change:: diff --git a/doc/build/changelog/changelog_10.rst b/doc/build/changelog/changelog_10.rst index 7f73fa9e4..195f0f498 100644 --- a/doc/build/changelog/changelog_10.rst +++ b/doc/build/changelog/changelog_10.rst @@ -1006,8 +1006,8 @@ :tickets: 3459 Added a :meth:`.ColumnElement.cast` method which performs the same - purpose as the standalone :func:`.cast` function. Pull request - courtesy Sebastian Bank. + purpose as the standalone :func:`.expression.cast` function. Pull + request courtesy Sebastian Bank. .. change:: :tags: bug, engine @@ -1181,7 +1181,7 @@ Repaired the :class:`.ExcludeConstraint` construct to support common features that other objects like :class:`.Index` now do, that the column expression may be specified as an arbitrary SQL - expression such as :obj:`.cast` or :obj:`.text`. + expression such as :obj:`.expression.cast` or :obj:`.expression.text`. .. change:: :tags: feature, postgresql @@ -1206,14 +1206,13 @@ :tags: bug, orm :tickets: 3448 - Fixed an unexpected-use regression whereby custom :class:`.Comparator` - objects that made use of the ``__clause_element__()`` method and - returned an object that was an ORM-mapped - :class:`.InstrumentedAttribute` and not explicitly a - :class:`.ColumnElement` would fail to be correctly - handled when passed as an expression to :meth:`.Session.query`. - The logic in 0.9 happened to succeed on this, so this use case is now - supported. + Fixed an unexpected-use regression whereby custom + :class:`.types.TypeEngine.Comparator` objects that made use of the + ``__clause_element__()`` method and returned an object that was an + ORM-mapped :class:`.InstrumentedAttribute` and not explicitly a + :class:`.ColumnElement` would fail to be correctly handled when passed + as an expression to :meth:`.Session.query`. The logic in 0.9 happened + to succeed on this, so this use case is now supported. .. change:: :tags: bug, sql diff --git a/doc/build/changelog/changelog_11.rst b/doc/build/changelog/changelog_11.rst index d4eef6811..c50322ad1 100644 --- a/doc/build/changelog/changelog_11.rst +++ b/doc/build/changelog/changelog_11.rst @@ -22,10 +22,6 @@ .. changelog:: - :version: 1.1.19 - :include_notes_from: unreleased_11 - -.. changelog:: :version: 1.1.18 :released: March 6, 2018 diff --git a/doc/build/changelog/changelog_12.rst b/doc/build/changelog/changelog_12.rst index 4d8d41bbb..e5c145642 100644 --- a/doc/build/changelog/changelog_12.rst +++ b/doc/build/changelog/changelog_12.rst @@ -13,10 +13,6 @@ .. changelog:: - :version: 1.2.20 - :include_notes_from: unreleased_12 - -.. changelog:: :version: 1.2.19 :released: April 15, 2019 @@ -882,15 +878,15 @@ :released: May 28, 2018 .. change:: - :tags: bug, orm - :tickets: 4256 + :tags: bug, orm + :tickets: 4256 - Fixed regression in 1.2.7 caused by :ticket:`4228`, which itself was fixing - a 1.2-level regression, where the ``query_cls`` callable passed to a - :class:`.Session` was assumed to be a subclass of :class:`.Query` with - class method availability, as opposed to an arbitrary callable. In - particular, the dogpile caching example illustrates ``query_cls`` as a - function and not a :class:`.Query` subclass. + Fixed regression in 1.2.7 caused by :ticket:`4228`, which itself was fixing + a 1.2-level regression, where the ``query_cls`` callable passed to a + :class:`.Session` was assumed to be a subclass of :class:`.Query` with + class method availability, as opposed to an arbitrary callable. In + particular, the dogpile caching example illustrates ``query_cls`` as a + function and not a :class:`.Query` subclass. .. change:: :tags: bug, engine @@ -928,15 +924,15 @@ .. change:: - :tags: bug, ext - :tickets: 4247 + :tags: bug, ext + :tickets: 4247 - The horizontal sharding extension now makes use of the identity token - added to ORM identity keys as part of :ticket:`4137`, when an object - refresh or column-based deferred load or unexpiration operation occurs. - Since we know the "shard" that the object originated from, we make - use of this value when refreshing, thereby avoiding queries against - other shards that don't match this object's identity in any case. + The horizontal sharding extension now makes use of the identity token + added to ORM identity keys as part of :ticket:`4137`, when an object + refresh or column-based deferred load or unexpiration operation occurs. + Since we know the "shard" that the object originated from, we make + use of this value when refreshing, thereby avoiding queries against + other shards that don't match this object's identity in any case. .. change:: :tags: bug, sql @@ -1009,15 +1005,15 @@ of these issues as part of issue :ticket:`4258`. .. change:: - :tags: bug, ext - :tickets: 4266 + :tags: bug, ext + :tickets: 4266 - Fixed a race condition which could occur if automap - :meth:`.AutomapBase.prepare` were used within a multi-threaded context - against other threads which may call :func:`.configure_mappers` as a - result of use of other mappers. The unfinished mapping work of automap - is particularly sensitive to being pulled in by a - :func:`.configure_mappers` step leading to errors. + Fixed a race condition which could occur if automap + :meth:`.AutomapBase.prepare` were used within a multi-threaded context + against other threads which may call :func:`.configure_mappers` as a + result of use of other mappers. The unfinished mapping work of automap + is particularly sensitive to being pulled in by a + :func:`.configure_mappers` step leading to errors. .. change:: :tags: bug, orm @@ -1029,12 +1025,12 @@ the post criteria feature is now used by the lazy loader. .. change:: - :tags: bug, tests - :tickets: 4249 + :tags: bug, tests + :tickets: 4249 - Fixed a bug in the test suite where if an external dialect returned - ``None`` for ``server_version_info``, the exclusion logic would raise an - ``AttributeError``. + Fixed a bug in the test suite where if an external dialect returned + ``None`` for ``server_version_info``, the exclusion logic would raise an + ``AttributeError``. .. change:: :tags: bug, orm @@ -1954,18 +1950,18 @@ index implicitly added by Oracle onto the primary key columns. .. change:: - :tags: bug, orm - :tickets: 4071 + :tags: bug, orm + :tickets: 4071 - Removed the warnings that are emitted when the LRU caches employed - by the mapper as well as loader strategies reach their threshold; the - purpose of this warning was at first a guard against excess cache keys - being generated but became basically a check on the "creating many - engines" antipattern. While this is still an antipattern, the presence - of test suites which both create an engine per test as well as raise - on all warnings will be an inconvenience; it should not be critical - that such test suites change their architecture just for this warning - (though engine-per-test suite is always better). + Removed the warnings that are emitted when the LRU caches employed + by the mapper as well as loader strategies reach their threshold; the + purpose of this warning was at first a guard against excess cache keys + being generated but became basically a check on the "creating many + engines" antipattern. While this is still an antipattern, the presence + of test suites which both create an engine per test as well as raise + on all warnings will be an inconvenience; it should not be critical + that such test suites change their architecture just for this warning + (though engine-per-test suite is always better). .. change:: :tags: bug, orm @@ -2093,11 +2089,12 @@ Internal refinements to the :class:`.Enum`, :class:`.Interval`, and :class:`.Boolean` types, which now extend a common mixin :class:`.Emulated` that indicates a type that provides Python-side - emulation of a DB native type, switching out to the DB native type when a - supporting backend is in use. The PostgreSQL :class:`.INTERVAL` type - when used directly will now include the correct type coercion rules for - SQL expressions that also take effect for :class:`.sqltypes.Interval` - (such as adding a date to an interval yields a datetime). + emulation of a DB native type, switching out to the DB native type when + a supporting backend is in use. The PostgreSQL + :class:`.postgresql.INTERVAL` type when used directly will now include + the correct type coercion rules for SQL expressions that also take + effect for :class:`.sqltypes.Interval` (such as adding a date to an + interval yields a datetime). .. change:: diff --git a/doc/build/changelog/migration_08.rst b/doc/build/changelog/migration_08.rst index f8487d51d..b707a912c 100644 --- a/doc/build/changelog/migration_08.rst +++ b/doc/build/changelog/migration_08.rst @@ -413,7 +413,7 @@ and :meth:`.PropComparator.has`:: .. seealso:: - :ref:`of_type` + :ref:`inheritance_of_type` :ticket:`2438` :ticket:`1106` @@ -960,7 +960,7 @@ when features such as :meth:`.MetaData.create_all` and :func:`.cast` is used:: :ticket:`2276` "Prefixes" now supported for :func:`.update`, :func:`.delete` -------------------------------------------------------------- +---------------------------------------------------------------------------- Geared towards MySQL, a "prefix" can be rendered within any of these constructs. E.g.:: diff --git a/doc/build/changelog/migration_09.rst b/doc/build/changelog/migration_09.rst index 376e83236..df4a2c57f 100644 --- a/doc/build/changelog/migration_09.rst +++ b/doc/build/changelog/migration_09.rst @@ -83,7 +83,7 @@ accessor:: .. _migration_2736: :meth:`.Query.select_from` no longer applies the clause to corresponding entities ---------------------------------------------------------------------------------- +----------------------------------------------------------------------------------------------- The :meth:`.Query.select_from` method has been popularized in recent versions as a means of controlling the first thing that a :class:`.Query` object @@ -564,8 +564,9 @@ by that of most database documentation:: -- 0.9 behavior x = :x_1 COLLATE en_EN -The potentially backwards incompatible change arises if the :meth:`.collate` -operator is being applied to the right-hand column, as follows:: +The potentially backwards incompatible change arises if the +:meth:`.ColumnOperators.collate` operator is being applied to the right-hand +column, as follows:: print(column('x') == literal('somevalue').collate("en_EN")) diff --git a/doc/build/changelog/migration_13.rst b/doc/build/changelog/migration_13.rst index b749f5623..6f99bb708 100644 --- a/doc/build/changelog/migration_13.rst +++ b/doc/build/changelog/migration_13.rst @@ -1321,13 +1321,12 @@ SQL text from being rendered directly. "threadlocal" engine strategy deprecated ----------------------------------------- -The :ref:`"threadlocal" engine strategy <threadlocal_strategy>` was added -around SQLAlchemy 0.2, as a solution to the problem that the standard way of -operating in SQLAlchemy 0.1, which can be summed up as "threadlocal -everything", was found to be lacking. In retrospect, it seems fairly absurd -that by SQLAlchemy's first releases which were in every regard "alpha", that -there was concern that too many users had already settled on the existing API -to simply change it. +The "threadlocal engine strategy" was added around SQLAlchemy 0.2, as a +solution to the problem that the standard way of operating in SQLAlchemy 0.1, +which can be summed up as "threadlocal everything", was found to be lacking. +In retrospect, it seems fairly absurd that by SQLAlchemy's first releases which +were in every regard "alpha", that there was concern that too many users had +already settled on the existing API to simply change it. The original usage model for SQLAlchemy looked like this:: diff --git a/doc/build/changelog/migration_14.rst b/doc/build/changelog/migration_14.rst index b35818075..a5a3f83d0 100644 --- a/doc/build/changelog/migration_14.rst +++ b/doc/build/changelog/migration_14.rst @@ -23,7 +23,7 @@ What's New in SQLAlchemy 1.4? Behavioral Changes - General ============================ -.. _change_change_deferred_construction: +.. _change_deferred_construction: Many Core and ORM statement objects now perform much of their validation in the compile phase diff --git a/doc/build/changelog/migration_20.rst b/doc/build/changelog/migration_20.rst index d9fc6c6c4..c712ab991 100644 --- a/doc/build/changelog/migration_20.rst +++ b/doc/build/changelog/migration_20.rst @@ -731,7 +731,7 @@ ORM Query Unified with Core Select Tenative overall, however there will almost definitely be architectural changes in :class:`.Query` that move it closer to - :meth:`.select`. + :func:`.select`. The ``session.query(<cls>)`` pattern itself will likely **not** be fully removed. As this pattern is extremely prevalent and numerous within any diff --git a/doc/build/changelog/unreleased_10/4065.rst b/doc/build/changelog/unreleased_10/4065.rst deleted file mode 100644 index 375ce8cf1..000000000 --- a/doc/build/changelog/unreleased_10/4065.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. change:: - :tags: bug, mysql - :tickets: 4065 - :versions: 1.2.0b3, 1.1.14 - - mysqlclient as of 1.3.11 changed the exception - class for a particular disconnect situation from - InterfaceError to InternalError; the disconnection - detection logic now accommodates this. diff --git a/doc/build/changelog/unreleased_10/README.txt b/doc/build/changelog/unreleased_10/README.txt deleted file mode 100644 index 86b91221f..000000000 --- a/doc/build/changelog/unreleased_10/README.txt +++ /dev/null @@ -1,11 +0,0 @@ -Individual per-changelog files go here -in .rst format, which are pulled in by -changelog (version 0.4.0 or higher) to -be rendered into the changelog_xx.rst file. -At release time, the files here are removed and written -directly into the changelog. - -Rationale is so that multiple changes being merged -into gerrit don't produce conflicts. Note that -gerrit does not support custom merge handlers unlike -git itself. diff --git a/doc/build/changelog/unreleased_11/README.txt b/doc/build/changelog/unreleased_11/README.txt deleted file mode 100644 index 1d2b3446e..000000000 --- a/doc/build/changelog/unreleased_11/README.txt +++ /dev/null @@ -1,12 +0,0 @@ -Individual per-changelog files go here -in .rst format, which are pulled in by -changelog (version 0.4.0 or higher) to -be rendered into the changelog_xx.rst file. -At release time, the files here are removed and written -directly into the changelog. - -Rationale is so that multiple changes being merged -into gerrit don't produce conflicts. Note that -gerrit does not support custom merge handlers unlike -git itself. - diff --git a/doc/build/changelog/unreleased_12/README.txt b/doc/build/changelog/unreleased_12/README.txt deleted file mode 100644 index 1d2b3446e..000000000 --- a/doc/build/changelog/unreleased_12/README.txt +++ /dev/null @@ -1,12 +0,0 @@ -Individual per-changelog files go here -in .rst format, which are pulled in by -changelog (version 0.4.0 or higher) to -be rendered into the changelog_xx.rst file. -At release time, the files here are removed and written -directly into the changelog. - -Rationale is so that multiple changes being merged -into gerrit don't produce conflicts. Note that -gerrit does not support custom merge handlers unlike -git itself. - diff --git a/doc/build/changelog/unreleased_13/4138.rst b/doc/build/changelog/unreleased_13/4138.rst new file mode 100644 index 000000000..fd8f0eb90 --- /dev/null +++ b/doc/build/changelog/unreleased_13/4138.rst @@ -0,0 +1,5 @@ +.. change:: + :tags: schema + :tickets: 4138 + + Add ``comment`` attribute to :class:`.Column` ``__repr__`` method. diff --git a/doc/build/changelog/unreleased_13/README.txt b/doc/build/changelog/unreleased_13/README.txt deleted file mode 100644 index 1d2b3446e..000000000 --- a/doc/build/changelog/unreleased_13/README.txt +++ /dev/null @@ -1,12 +0,0 @@ -Individual per-changelog files go here -in .rst format, which are pulled in by -changelog (version 0.4.0 or higher) to -be rendered into the changelog_xx.rst file. -At release time, the files here are removed and written -directly into the changelog. - -Rationale is so that multiple changes being merged -into gerrit don't produce conflicts. Note that -gerrit does not support custom merge handlers unlike -git itself. - diff --git a/doc/build/changelog/unreleased_14/README.txt b/doc/build/changelog/unreleased_14/README.txt deleted file mode 100644 index 1d2b3446e..000000000 --- a/doc/build/changelog/unreleased_14/README.txt +++ /dev/null @@ -1,12 +0,0 @@ -Individual per-changelog files go here -in .rst format, which are pulled in by -changelog (version 0.4.0 or higher) to -be rendered into the changelog_xx.rst file. -At release time, the files here are removed and written -directly into the changelog. - -Rationale is so that multiple changes being merged -into gerrit don't produce conflicts. Note that -gerrit does not support custom merge handlers unlike -git itself. - diff --git a/doc/build/conf.py b/doc/build/conf.py index 805290a89..266b20e08 100644 --- a/doc/build/conf.py +++ b/doc/build/conf.py @@ -37,6 +37,7 @@ extensions = [ "changelog", "sphinx_paramlinks", ] +needs_extensions = {"zzzeeksphinx": "1.1.2"} # Add any paths that contain templates here, relative to this directory. # not sure why abspath() is needed here, some users @@ -88,6 +89,9 @@ changelog_render_changeset = "http://www.sqlalchemy.org/trac/changeset/%s" exclude_patterns = ["build", "**/unreleased*/*"] +# zzzeeksphinx makes these conversions when it is rendering the +# docstrings classes, methods, and functions within the scope of +# Sphinx autodoc autodocmods_convert_modname = { "sqlalchemy.sql.sqltypes": "sqlalchemy.types", "sqlalchemy.sql.type_api": "sqlalchemy.types", @@ -97,8 +101,10 @@ autodocmods_convert_modname = { "sqlalchemy.sql.dml": "sqlalchemy.sql.expression", "sqlalchemy.sql.ddl": "sqlalchemy.schema", "sqlalchemy.sql.base": "sqlalchemy.sql.expression", + "sqlalchemy.event.base": "sqlalchemy.event", "sqlalchemy.engine.base": "sqlalchemy.engine", "sqlalchemy.engine.result": "sqlalchemy.engine", + "sqlalchemy.util._collections": "sqlalchemy.util", } autodocmods_convert_modname_w_class = { @@ -106,6 +112,42 @@ autodocmods_convert_modname_w_class = { ("sqlalchemy.sql.base", "DialectKWArgs"): "sqlalchemy.sql.base", } +# on the referencing side, a newer zzzeeksphinx extension +# applies shorthand symbols to references so that we can have short +# names that are still using absolute references. +zzzeeksphinx_module_prefixes = { + "_sa": "sqlalchemy", + "_engine": "sqlalchemy.engine", + "_schema": "sqlalchemy.schema", + "_types": "sqlalchemy.types", + "_expression": "sqlalchemy.sql.expression", + "_functions": "sqlalchemy.sql.functions", + "_pool": "sqlalchemy.pool", + "_event": "sqlalchemy.event", + "_events": "sqlalchemy.events", + "_exc": "sqlalchemy.exc", + "_reflection": "sqlalchemy.engine.reflection", + "_orm": "sqlalchemy.orm", + "_query": "sqlalchemy.orm.query", + "_ormevent": "sqlalchemy.orm.event", + "_ormexc": "sqlalchemy.orm.exc", + "_baked": "sqlalchemy.ext.baked", + "_associationproxy": "sqlalchemy.ext.associationproxy", + "_automap": "sqlalchemy.ext.automap", + "_hybrid": "sqlalchemy.ext.hybrid", + "_compilerext": "sqlalchemy.ext.compiler", + "_mutable": "sqlalchemy.ext.mutable", + "_declarative": "sqlalchemy.ext.declarative", + "_future": "sqlalchemy.future", + "_futureorm": "sqlalchemy.future.orm", + "_postgresql": "sqlalchemy.dialects.postgresql", + "_mysql": "sqlalchemy.dialects.mysql", + "_mssql": "sqlalchemy.dialects.mssql", + "_oracle": "sqlalchemy.dialects.oracle", + "_sqlite": "sqlalchemy.dialects.sqlite", +} + + # The encoding of source files. # source_encoding = 'utf-8-sig' diff --git a/doc/build/core/connections.rst b/doc/build/core/connections.rst index 7c2793f34..2191dee6e 100644 --- a/doc/build/core/connections.rst +++ b/doc/build/core/connections.rst @@ -75,7 +75,7 @@ any transactional state or locks are removed, and the connection is ready for its next use. .. deprecated:: 2.0 The :class:`.ResultProxy` object is replaced in SQLAlchemy - 2.0 with a newly refined object known as :class:`.Result`. + 2.0 with a newly refined object known as :class:`.future.Result`. Our example above illustrated the execution of a textual SQL string, which should be invoked by using the :func:`.text` construct to indicate that diff --git a/doc/build/core/dml.rst b/doc/build/core/dml.rst index d83a52e7b..d116b67a5 100644 --- a/doc/build/core/dml.rst +++ b/doc/build/core/dml.rst @@ -16,19 +16,29 @@ constructs build on the intermediary :class:`.ValuesBase`. .. autoclass:: Delete :members: - :inherited-members: + + .. automethod:: Delete.where + + .. automethod:: Delete.returning .. autoclass:: Insert :members: - :inherited-members: + + .. automethod:: Insert.values + + .. automethod:: Insert.returning .. autoclass:: Update - :members: - :inherited-members: + :members: + + .. automethod:: Update.returning + + .. automethod:: Update.where + + .. automethod:: Update.values .. autoclass:: sqlalchemy.sql.expression.UpdateBase - :members: - :inherited-members: + :members: .. autoclass:: sqlalchemy.sql.expression.ValuesBase :members: diff --git a/doc/build/core/inspection.rst b/doc/build/core/inspection.rst index 313b4d6e7..01343102d 100644 --- a/doc/build/core/inspection.rst +++ b/doc/build/core/inspection.rst @@ -5,7 +5,9 @@ Runtime Inspection API ====================== .. automodule:: sqlalchemy.inspection - :members: + +.. autofunction:: sqlalchemy.inspect + Available Inspection Targets ---------------------------- diff --git a/doc/build/core/selectable.rst b/doc/build/core/selectable.rst index 4771222e8..2f69c0200 100644 --- a/doc/build/core/selectable.rst +++ b/doc/build/core/selectable.rst @@ -78,13 +78,16 @@ elements are themselves :class:`.ColumnElement` subclasses). .. autoclass:: Select :members: - :inherited-members: + :inherited-members: ClauseElement + :exclude-members: memoized_attribute, memoized_instancemethod .. autoclass:: Selectable :members: .. autoclass:: SelectBase :members: + :inherited-members: ClauseElement + :exclude-members: memoized_attribute, memoized_instancemethod .. autoclass:: Subquery :members: diff --git a/doc/build/errors.rst b/doc/build/errors.rst index ed5583b12..43e0b9fa4 100644 --- a/doc/build/errors.rst +++ b/doc/build/errors.rst @@ -489,7 +489,7 @@ Above, the ``cprop`` attribute is used inline before it has been mapped, however this ``cprop`` attribute is not a :class:`.Column`, it's a :class:`.ColumnProperty`, which is an interim object and therefore does not have the full functionality of either the :class:`.Column` object -or the :class:`.InstrmentedAttribute` object that will be mapped onto the +or the :class:`.InstrumentedAttribute` object that will be mapped onto the ``Bar`` class once the declarative process is complete. While the :class:`.ColumnProperty` does have a ``__clause_element__()`` method, diff --git a/doc/build/faq/metadata_schema.rst b/doc/build/faq/metadata_schema.rst index 2d1527294..94cbb1787 100644 --- a/doc/build/faq/metadata_schema.rst +++ b/doc/build/faq/metadata_schema.rst @@ -50,7 +50,7 @@ Does SQLAlchemy support ALTER TABLE, CREATE VIEW, CREATE TRIGGER, Schema Upgrade General ALTER support isn't present in SQLAlchemy directly. For special DDL on an ad-hoc basis, the :class:`.DDL` and related constructs can be used. -See :doc:`core/ddl` for a discussion on this subject. +See :ref:`metadata_ddl_toplevel` for a discussion on this subject. A more comprehensive option is to use schema migration tools, such as Alembic or SQLAlchemy-Migrate; see :ref:`schema_migrations` for discussion on this. diff --git a/doc/build/faq/performance.rst b/doc/build/faq/performance.rst index c30e96abb..65d6cc460 100644 --- a/doc/build/faq/performance.rst +++ b/doc/build/faq/performance.rst @@ -212,7 +212,7 @@ the profiling output of this intentionally slow operation can be seen like this: that is, we see many expensive calls within the ``type_api`` system, and the actual time consuming thing is the ``time.sleep()`` call. -Make sure to check the :doc:`Dialect documentation <dialects/index>` +Make sure to check the :ref:`Dialect documentation <dialect_toplevel>` for notes on known performance tuning suggestions at this level, especially for databases like Oracle. There may be systems related to ensuring numeric accuracy or string processing that may not be needed in all cases. @@ -295,14 +295,14 @@ ORM as a first-class component. For the use case of fast bulk inserts, the SQL generation and execution system that the ORM builds on top of -is part of the :doc:`Core <core/tutorial>`. Using this system directly, we can produce an INSERT that +is part of the :ref:`Core <sqlexpression_toplevel>`. Using this system directly, we can produce an INSERT that is competitive with using the raw database API directly. .. note:: - When using the psycopg2 dialect, consider making use of the - :ref:`batch execution helpers <psycopg2_batch_mode>` feature of psycopg2, - now supported directly by the SQLAlchemy psycopg2 dialect. + When using the psycopg2 dialect, consider making use of the :ref:`batch + execution helpers <psycopg2_executemany_mode>` feature of psycopg2, now + supported directly by the SQLAlchemy psycopg2 dialect. Alternatively, the SQLAlchemy ORM offers the :ref:`bulk_operations` suite of methods, which provide hooks into subsections of the unit of diff --git a/doc/build/glossary.rst b/doc/build/glossary.rst index c431fce3d..83bf0b43a 100644 --- a/doc/build/glossary.rst +++ b/doc/build/glossary.rst @@ -9,6 +9,25 @@ Glossary .. glossary:: :sorted: + relational + relational algebra + + An algrebraic system developed by Edgar F. Codd that is used for + modelling and querying the data stored in relational databases. + + .. seealso:: + + `Relational Algebra (via Wikipedia) <https://en.wikipedia.org/wiki/Relational_algebra>`_ + + selectable + A term used in SQLAlchemy to describe a SQL construct that represents + a collection of rows. It's largely similar to the concept of a + "relation" in :term:`relational algebra`. In SQLAlchemy, objects + that subclass the :class:`.Selectable` class are considered to be + usable as "selectables" when using SQLAlchemy Core. The two most + common constructs are that of the :class:`.Table` and that of the + :class:`.Select` statement. + annotations Annotations are a concept used internally by SQLAlchemy in order to store additional information along with :class:`.ClauseElement` objects. A Python @@ -121,6 +140,79 @@ Glossary :term:`DDL` + metadata + table metadata + The term "metadata" generally refers to "data that describes data"; + data that itself represents the format and/or structure of some other + kind of data. In SQLAlchemy, the term "metadata" typically refers to + the :class:`.MetaData` construct, which is a collection of information + about the tables, columns, constraints, and other :term:`DDL` objects + that may exist in a particular database. + + .. seealso:: + + `Metadata Mapping (via Martin Fowler) <https://www.martinfowler.com/eaaCatalog/metadataMapping.html>`_ + + version id column + In SQLAlchemy, this refers to the use of a particular table column that + tracks the "version" of a particular row, as the row changes values. While + there are different kinds of relational patterns that make use of a + "version id column" in different ways, SQLAlchemy's ORM includes a particular + feature that allows for such a column to be configured as a means of + testing for stale data when a row is being UPDATEd with new information. + If the last known "version" of this column does not match that of the + row when we try to put new data into the row, we know that we are + acting on stale information. + + There are also other ways of storing "versioned" rows in a database, + often referred to as "temporal" data. In addition to SQLAlchemy's + versioning feature, a few more examples are also present in the + documentation, see the links below. + + .. seealso:: + + :ref:`mapper_version_counter` - SQLAlchemy's built-in version id feature. + + :ref:`examples_versioning` - other examples of mappings that version rows + temporally. + + registry + An object, typically globally accessible, that contains long-lived + information about some program state that is generally useful to many + parts of a program. + + .. seealso:: + + `Registry (via Martin Fowler) <https://martinfowler.com/eaaCatalog/registry.html>`_ + + cascade + A term used in SQLAlchemy to describe how an ORM persistence action that + takes place on a particular object would extend into other objects + which are directly associated with that object. In SQLAlchemy, these + object associations are configured using the :func:`.relationship` + construct. :func:`.relationship` contains a parameter called + :paramref:`.relationship.cascade` which provides options on how certain + persistence operations may cascade. + + The term "cascades" as well as the general architecture of this system + in SQLAlchemy was borrowed, for better or worse, from the Hibernate + ORM. + + .. seealso:: + + :ref:`unitofwork_cascades` + + dialect + In SQLAlchemy, the "dialect" is a Python object that represents information + and methods that allow database operations to proceed on a particular + kind of database backend and a particular kind of Python driver (or + :term`DBAPI`) for that database. SQLAlchemy dialects are subclasses + of the :class:`.Dialect` class. + + .. seealso:: + + :ref:`engines_toplevel` + discriminator A result-set column which is used during :term:`polymorphic` loading to determine what kind of mapped class should be applied to a particular @@ -159,7 +251,16 @@ Glossary .. seealso:: - Martin Fowler - Identity Map - http://martinfowler.com/eaaCatalog/identityMap.html + `Identity Map (via Martin Fowler) <http://martinfowler.com/eaaCatalog/identityMap.html>`_ + + lazy initialization + A tactic of delaying some initialization action, such as creating objects, + populating data, or establishing connectivity to other services, until + those resources are required. + + .. seealso:: + + `Lazy initialization (via Wikipedia) <https://en.wikipedia.org/wiki/Lazy_initialization>`_ lazy load lazy loads @@ -174,16 +275,33 @@ Glossary the complexity and time spent within object fetches can sometimes be reduced, in that attributes for related tables don't need to be addressed - immediately. + immediately. Lazy loading is the opposite of :term:`eager loading`. .. seealso:: - `Lazy Load (on Martin Fowler) <http://martinfowler.com/eaaCatalog/lazyLoad.html>`_ + `Lazy Load (via Martin Fowler) <http://martinfowler.com/eaaCatalog/lazyLoad.html>`_ :term:`N plus one problem` :doc:`orm/loading_relationships` + eager load + eager loads + eager loaded + eager loading + + In object relational mapping, an "eager load" refers to + an attribute that is populated with its database-side value + at the same time as when the object itself is loaded from the database. + In SQLAlchemy, "eager loading" usually refers to related collections + of objects that are mapped using the :func:`.relationship` construct. + Eager loading is the opposite of :term:`lazy loading`. + + .. seealso:: + + :doc:`orm/loading_relationships` + + mapping mapped We say a class is "mapped" when it has been passed through the @@ -191,7 +309,7 @@ Glossary class with a database table or other :term:`selectable` construct, so that instances of it can be persisted using a :class:`.Session` as well as loaded using a - :class:`.Query`. + :class:`.query.Query`. N plus one problem The N plus one problem is a common side effect of the @@ -239,7 +357,7 @@ Glossary The two SQLAlchemy objects that make the most use of method chaining are the :class:`~.expression.Select` - object and the :class:`~.orm.query.Query` object. + object and the :class:`.orm.query.Query` object. For example, a :class:`~.expression.Select` object can be assigned two expressions to its WHERE clause as well as an ORDER BY clause by calling upon the :meth:`~.Select.where` @@ -325,7 +443,7 @@ Glossary .. seealso:: - `Domain Model (wikipedia) <http://en.wikipedia.org/wiki/Domain_model>`_ + `Domain Model (via Wikipedia) <http://en.wikipedia.org/wiki/Domain_model>`_ unit of work This pattern is where the system transparently keeps @@ -336,7 +454,7 @@ Glossary .. seealso:: - `Unit of Work by Martin Fowler <http://martinfowler.com/eaaCatalog/unitOfWork.html>`_ + `Unit of Work (via Martin Fowler) <http://martinfowler.com/eaaCatalog/unitOfWork.html>`_ :doc:`orm/session` @@ -530,7 +648,7 @@ Glossary :term:`durability` - http://en.wikipedia.org/wiki/ACID_Model + `ACID Model (via Wikipedia) <http://en.wikipedia.org/wiki/ACID_Model>`_ atomicity Atomicity is one of the components of the :term:`ACID` model, @@ -545,7 +663,7 @@ Glossary :term:`ACID` - http://en.wikipedia.org/wiki/Atomicity_(database_systems) + `Atomicity (via Wikipedia) <http://en.wikipedia.org/wiki/Atomicity_(database_systems)>`_ consistency Consistency is one of the components of the :term:`ACID` model, @@ -560,10 +678,11 @@ Glossary :term:`ACID` - http://en.wikipedia.org/wiki/Consistency_(database_systems) + `Consistency (via Wikipedia) <http://en.wikipedia.org/wiki/Consistency_(database_systems)>`_ isolation isolated + isolation level The isolation property of the :term:`ACID` model ensures that the concurrent execution of transactions results in a system state that would be @@ -577,7 +696,57 @@ Glossary :term:`ACID` - http://en.wikipedia.org/wiki/Isolation_(database_systems) + `Isolation (via Wikipedia) <http://en.wikipedia.org/wiki/Isolation_(database_systems)>`_ + + :term:`read uncommitted` + + :term:`read committed` + + :term:`repeatable read` + + :term:`serializable` + + repeatable read + One of the four database :term:`isolation` levels, repeatable read + features all of the isolation of :term:`read committed`, and + additionally features that any particular row that is read within a + transaction is guaranteed from that point to not have any subsequent + external changes in value (i.e. from other concurrent UPDATE + statements) for the duration of that transaction. + + read committed + One of the four database :term:`isolation` levels, read committed + features that the transaction will not be exposed to any data from + other concurrent transactions that has not been committed yet, + preventing so-called "dirty reads". However, under read committed + there can be non-repeatable reads, meaning data in a row may change + when read a second time if another transaction has committed changes. + + read uncommitted + One of the four database :term:`isolation` levels, read uncommitted + features that changes made to database data within a transaction will + not become permanent until the transaction is committed. However, + within read uncommitted, it may be possible for data that is not + committed in other transactions to be viewable within the scope of + another transaction; these are known as "dirty reads". + + serializable + One of the four database :term:`isolation` levels, serializable + features all of the isolation of :term:`repeatable read`, and + additionally within a lock-based approach guarantees that so-called + "phantom reads" cannot occur; this means that rows which are INSERTed + or DELETEd within the scope of other transactions will not be + detectable within this transaction. A row that is read within this + transaction is guaranteed to continue existing, and a row that does not + exist is guaranteed that it cannot appear of inserted from another + transaction. + + Serializable isolation typically relies upon locking of rows or ranges + of rows in order to achieve this effect and can increase the chance of + deadlocks and degrade performance. There are also non-lock based + schemes however these necessarily rely upon rejecting transactions if + write collisions are detected. + durability Durability is a property of the :term:`ACID` model @@ -593,7 +762,7 @@ Glossary :term:`ACID` - http://en.wikipedia.org/wiki/Durability_(database_systems) + `Durability (via Wikipedia) <http://en.wikipedia.org/wiki/Durability_(database_systems)>`_ RETURNING This is a non-SQL standard clause provided in various forms by @@ -970,7 +1139,7 @@ Glossary :term:`primary key` - http://en.wikipedia.org/wiki/Candidate_key + `Candidate key (via Wikipedia) <http://en.wikipedia.org/wiki/Candidate_key>`_ https://www.databasestar.com/database-keys/ @@ -978,7 +1147,7 @@ Glossary primary key constraint A :term:`constraint` that uniquely defines the characteristics - of each :term:`row`. The primary key has to consist of + of each row in a table. The primary key has to consist of characteristics that cannot be duplicated by any other row. The primary key may consist of a single attribute or multiple attributes in combination. @@ -998,7 +1167,7 @@ Glossary .. seealso:: - http://en.wikipedia.org/wiki/Primary_Key + `Primary key (via Wikipedia) <http://en.wikipedia.org/wiki/Primary_Key>`_ foreign key constraint A referential constraint between two tables. A foreign key is a field or set of fields in a @@ -1016,7 +1185,7 @@ Glossary .. seealso:: - http://en.wikipedia.org/wiki/Foreign_key_constraint + `Foreign Key Constraint (via Wikipedia) <http://en.wikipedia.org/wiki/Foreign_key_constraint>`_ check constraint @@ -1036,7 +1205,7 @@ Glossary .. seealso:: - http://en.wikipedia.org/wiki/Check_constraint + `CHECK constraint (via Wikipedia) <http://en.wikipedia.org/wiki/Check_constraint>`_ unique constraint unique key index @@ -1053,7 +1222,7 @@ Glossary .. seealso:: - http://en.wikipedia.org/wiki/Unique_key#Defining_unique_keys + `Unique key (via Wikipedia) <http://en.wikipedia.org/wiki/Unique_key#Defining_unique_keys>`_ transient This describes one of the major object states which diff --git a/doc/build/orm/examples.rst b/doc/build/orm/examples.rst index d3a1f8d31..e8bb894fd 100644 --- a/doc/build/orm/examples.rst +++ b/doc/build/orm/examples.rst @@ -90,6 +90,8 @@ XML Persistence .. automodule:: examples.elementtree +.. _examples_versioning: + Versioning Objects ------------------ diff --git a/doc/build/orm/extensions/declarative/inheritance.rst b/doc/build/orm/extensions/declarative/inheritance.rst index f23410683..b98843816 100644 --- a/doc/build/orm/extensions/declarative/inheritance.rst +++ b/doc/build/orm/extensions/declarative/inheritance.rst @@ -248,4 +248,3 @@ on concrete inheritance for details. :ref:`concrete_inheritance` - :ref:`inheritance_concrete_helpers` diff --git a/doc/build/orm/join_conditions.rst b/doc/build/orm/join_conditions.rst index a317c6ecc..68a2949ff 100644 --- a/doc/build/orm/join_conditions.rst +++ b/doc/build/orm/join_conditions.rst @@ -700,6 +700,8 @@ complexity is kept within the middle. sometimes ways to make relationships like the above writable, this is generally complicated and error prone. +.. _relationship_non_primary_mapper: + .. _relationship_aliased_class: Relationship to Aliased Class diff --git a/doc/build/orm/mapping_api.rst b/doc/build/orm/mapping_api.rst index 99e0ba52d..250bd26a4 100644 --- a/doc/build/orm/mapping_api.rst +++ b/doc/build/orm/mapping_api.rst @@ -15,8 +15,8 @@ Class Mapping API .. autofunction:: sqlalchemy.orm.util.identity_key -.. autofunction:: sqlalchemy.orm.util.polymorphic_union +.. autofunction:: polymorphic_union -.. autoclass:: sqlalchemy.orm.mapper.Mapper +.. autoclass:: Mapper :members: diff --git a/doc/build/orm/nonstandard_mappings.rst b/doc/build/orm/nonstandard_mappings.rst index 7516d1b54..522359854 100644 --- a/doc/build/orm/nonstandard_mappings.rst +++ b/doc/build/orm/nonstandard_mappings.rst @@ -157,35 +157,21 @@ Multiple Mappers for One Class ============================== In modern SQLAlchemy, a particular class is mapped by only one so-called -**primary** mapper at a time. This mapper is involved in three main -areas of functionality: querying, persistence, and instrumentation of the -mapped class. The rationale of the primary mapper relates to the fact -that the :func:`.mapper` modifies the class itself, not only -persisting it towards a particular :class:`.Table`, but also :term:`instrumenting` -attributes upon the class which are structured specifically according to the -table metadata. It's not possible for more than one mapper -to be associated with a class in equal measure, since only one mapper can -actually instrument the class. - -However, there is a class of mapper known as the **non primary** mapper -which allows additional mappers to be associated with a class, but with -a limited scope of use. This scope typically applies to -being able to load rows from an alternate table or selectable unit, but -still producing classes which are ultimately persisted using the primary -mapping. The non-primary mapper is created using the classical style -of mapping against a class that is already mapped with a primary mapper, -and involves the use of the :paramref:`~sqlalchemy.orm.mapper.non_primary` -flag. - -The non primary mapper is of very limited use in modern SQLAlchemy, as the -task of being able to load classes from subqueries or other compound statements -can be now accomplished using the :class:`.Query` object directly. - -There is really only one use case for the non-primary mapper, which is that -we wish to build a :func:`.relationship` to such a mapper; this is useful -in the rare and advanced case that our relationship is attempting to join two -classes together using many tables and/or joins in between. An example of this -pattern is at :ref:`relationship_non_primary_mapper`. +**primary** mapper at a time. This mapper is involved in three main areas of +functionality: querying, persistence, and instrumentation of the mapped class. +The rationale of the primary mapper relates to the fact that the +:func:`.mapper` modifies the class itself, not only persisting it towards a +particular :class:`.Table`, but also :term:`instrumenting` attributes upon the +class which are structured specifically according to the table metadata. It's +not possible for more than one mapper to be associated with a class in equal +measure, since only one mapper can actually instrument the class. + +The concept of a "non-primary" mapper had existed for many versions of +SQLAlchemy however as of version 1.3 this feature is deprecated. The +one case where such a non-primary mapper is useful is when constructing +a relationship to a class against an alternative selectable. This +use case is now suited using the :class:`.aliased` construct and is described +at :ref:`relationship_aliased_class`. As far as the use case of a class that can actually be fully persisted to different tables under different scenarios, very early versions of diff --git a/doc/build/orm/session_state_management.rst b/doc/build/orm/session_state_management.rst index 2730bb8b2..8b4d7a572 100644 --- a/doc/build/orm/session_state_management.rst +++ b/doc/build/orm/session_state_management.rst @@ -543,8 +543,8 @@ or loaded with :meth:`~.Session.refresh` varies based on several factors, includ expired column-based attributes being accessed. * Regarding relationships, :meth:`~.Session.refresh` is more restrictive than - :meth:`~.Session.expire` with regards to attributes that aren't column-mapped. - Calling :meth:`.refresh` and passing a list of names that only includes + :meth:`.Session.expire` with regards to attributes that aren't column-mapped. + Calling :meth:`.Session.refresh` and passing a list of names that only includes relationship-mapped attributes will actually raise an error. In any case, non-eager-loading :func:`.relationship` attributes will not be included in any refresh operation. @@ -620,7 +620,7 @@ The second bullet has the important caveat that "it is also known that the isola allow this data to be visible." This means that it cannot be assumed that an UPDATE that happened on another database connection will yet be visible here locally; in many cases, it will not. This is why if one wishes to use -:meth:`.expire` or :meth:`.refresh` in order to view data between ongoing +:meth:`.Session.expire` or :meth:`.Session.refresh` in order to view data between ongoing transactions, an understanding of the isolation behavior in effect is essential. .. seealso:: diff --git a/doc/build/orm/tutorial.rst b/doc/build/orm/tutorial.rst index 0c9771e02..19fdd09bc 100644 --- a/doc/build/orm/tutorial.rst +++ b/doc/build/orm/tutorial.rst @@ -1651,7 +1651,7 @@ was emitted. If you want to reduce the number of queries (dramatically, in many we can apply an :term:`eager load` to the query operation. SQLAlchemy offers three types of eager loading, two of which are automatic, and a third which involves custom criterion. All three are usually invoked via functions known -as :term:`query options` which give additional instructions to the :class:`.Query` on how +as query options which give additional instructions to the :class:`.Query` on how we would like various attributes to be loaded, via the :meth:`.Query.options` method. Selectin Load diff --git a/doc/build/replacments/fix_xref_state.txt b/doc/build/replacments/fix_xref_state.txt new file mode 100644 index 000000000..380657df2 --- /dev/null +++ b/doc/build/replacments/fix_xref_state.txt @@ -0,0 +1,93 @@ +.MetaData _schema.MetaData +.ForeignKey _schema.ForeignKey +.ForeignKeyConstraint _schema.ForeignKeyConstraint +.PoolEvents _events.PoolEvents +.DisconnectionError _exc.DisconnectionError +.SADeprecationWarning _exc.SADeprecationWarning +.Engine _engine.Engine +.Pool _pool.Pool +.future _future +.inspect _sa.inspect +.Inspector _reflection.Inspector +.orm _orm +.Mapper _orm.Mapper +.engine _engine +.JSON _types.JSON +.postgresql _postgresql +.types _types +._mysql _mysql +.sqlite _sqlite +.array_agg _functions.array_agg +.TIMESTAMP _types.TIMESTAMP +.JSONB _postgresql.JSONB +.ARRAY _types.ARRAY +.mssql _mssql +.sqltypes _types +.functions _functions +.INTERVAL _postgresql.INTERVAL +.INTERVAL _oracle.INTERVAL +.oracle _oracle +.NCHAR _types.NCHAR +.Query _query.Query +.relationship _orm.relationship +.FromClause _expression.FromClause +.join _expression.join +.SelectBase _expression.SelectBase +.Load _orm.Load +.joinedload _orm.joinedload +.sql _expression +.sql.expression _expression +.INTEGER _types.INTEGER +.VARBINARY _types.VARBINARY +.joinedload_all _orm.joinedload_all +.Insert _expression.Insert +.Update _expression.Update +.Delete _expression.Delete +.insert _expression.insert +.update _expression.update +.delete _expression.delete +.select _expression.select +.expression _expression +.future _future.Subquery _expression.Subquery +.Select _expression.Select +.ReturnsRows _expression.ReturnsRows +.ColumnCollection _expression.ColumnCollection +.ColumnElement _expression.ColumnElement +.Selectable expression.Selectable +.Lateral _expression.Lateral +.HasPrefixes _expression.HasPrefixes +.prefix_with _expression.HasPrefixes.prefix_with +.ClauseElement _expression.ClauseElement +.HasSuffixes _expression.HasSuffixes +.suffix_with _expression.HasSuffixes.suffix_with +.Table _schema.Table +.Join _expression.Join +.Alias _expression.Alias +.TableSample _expression.TableSample +.CTE _expression.CTE +.HasCte _expression.HasCTE +.HasCTE _expression.HasCTE +.CompoundSelect _selectable.CompoundSelect +.TextualSelect _expression.TextualSelect +.TableClause _expression.TableClause +.schema _schema +.Values _expression.Values +.column _expression.column +.GenerativeSelect _expression.GenerativeSelect +.Column _schema.Column +.union _expression.union +.union_all _expression.union_all +.intersect _expression.intersect +.intersect_all _expression.intersect_all +.except _expression.except +.except_all _expression.except_all +.Text _expression.TextClause +.text _expression.text +.literal_column _expression.literal_column +.Connection _engine.Connection +.Engine _engine.Engine +.apply_labels _expression.Select.apply_labels +.BooleanClauseList _expression.BooleanClauseList +.ScalarSelect _expression.ScalarSelect +.Exists _expression.Exists +.TextClause _expression.TextClause |