summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/orm
Commit message (Collapse)AuthorAgeFilesLines
...
| * add new pattern for single inh column overrideMike Bayer2022-11-306-31/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Added a new parameter :paramref:`_orm.mapped_column.use_existing_column` to accommodate the use case of a single-table inheritance mapping that uses the pattern of more than one subclass indicating the same column to take place on the superclass. This pattern was previously possible by using :func:`_orm.declared_attr` in conjunction with locating the existing column in the ``.__table__`` of the superclass, however is now updated to work with :func:`_orm.mapped_column` as well as with pep-484 typing, in a simple and succinct way. Fixes: #8822 Change-Id: I2296a4a775da976c642c86567852cdc792610eaf
* | Add "compare" on dataclass fieldsSimon Schiele2022-11-302-7/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added :paramref:`_orm.mapped_column.compare` parameter to relevant ORM attribute constructs including :func:`_orm.mapped_column`, :func:`_orm.relationship` etc. to provide for the Python dataclasses ``compare`` parameter on ``field()``, when using the :ref:`orm_declarative_native_dataclasses` feature. Pull request courtesy Simon Schiele. Added an additional case for associationproxy into test_dc_transforms.py -> test_attribute_options Fixes: #8905 Closes: #8906 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8906 Pull-request-sha: ea9a53d2ca60befdd0c570013c0e57a78c11dd4a Change-Id: I390d043b06c1d668242325ef86e2f7b7dbfac442
* | Merge "Improve support for enum in mapped classes" into mainmike bayer2022-11-302-6/+38
|\ \ | |/ |/|
| * Improve support for enum in mapped classesFederico Caselli2022-11-292-6/+38
| | | | | | | | | | | | | | | | | | | | Add a new system by which TypeEngine objects have some say in how the declarative type registry interprets them. The Enum datatype is the primary target for this but it is hoped the system may be useful for other types as well. Fixes: #8859 Change-Id: I15ac3daee770408b5795746f47c1bbd931b7d26d
* | annotated / DC forms for association proxyMike Bayer2022-11-294-52/+98
|/ | | | | | | | | | | | | | | | | | | | | | | | Added support for the :func:`.association_proxy` extension function to take part within Python ``dataclasses`` configuration, when using the native dataclasses feature described at :ref:`orm_declarative_native_dataclasses`. Included are attribute-level arguments including :paramref:`.association_proxy.init` and :paramref:`.association_proxy.default_factory`. Documentation for association proxy has also been updated to use "Annotated Declarative Table" forms within examples, including type annotations used for :class:`.AssocationProxy` itself. Also modernized documentation examples in sqlalchemy.ext.mutable, which was not up to date even for 1.4 style code. Corrected typing for relationship(secondary) where "secondary" accepts a callable (i.e. lambda) as well Fixes: #8878 Fixes: #8876 Fixes: #8880 Change-Id: Ibd4f3591155a89f915713393e103e61cc072ed57
* update for mypy 1.0 devFederico Caselli2022-11-292-2/+2
| | | | | | | | | | | | | | | | As I need dmypy to work without facing [1], I am running the latest build of mypy which seems so far to finally not have that issue. update constructs that latest mypy is being more picky about, including better typing for the _NONE_NAME symbol used in constraints (porting those elements from the Enum patch at I15ac3daee770408b5795746f47c1bbd931b7d26d) [1] https://github.com/python/mypy/issues/12744 Change-Id: Ib3f56787fa65ea9bb2e6a0bccc4d99f54c516dad
* identify unresolvable Mapped typesMike Bayer2022-11-283-50/+89
| | | | | | | | | | | | | | | | | Fixed issue where use of an unknown datatype within a :class:`.Mapped` annotation for a column-based attribute would silently fail to map the attribute, rather than reporting an exception; an informative exception message is now raised. tighten up iteration of names on mapped classes to more fully exclude a large number of underscored names, so that we can avoid trying to look at annotations for them or anything else. centralize the "list of names we care about" more fully within _cls_attr_resolver and base it on underscore conventions we should usually ignore, with the exception of the few underscore names we want to see. Fixes: #8888 Change-Id: I3c0a1666579fe67b3c40cc74fa443b6f1de354ce
* Merge "improve column targeting issues with query_expression" into mainmike bayer2022-11-272-0/+4
|\
| * improve column targeting issues with query_expressionMike Bayer2022-11-252-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issues in :func:`_orm.with_expression` where expressions that were composed of columns within a subquery being SELECTed from, or when using ``.from_statement()``, would not render correct SQL **if** the expression had a label name that matched the attribute which used :func:`_orm.query_expression`, even when :func:`_orm.query_expression` had no default expression. For the moment, if the :func:`_orm.query_expression` **does** have a default expression, that label name is still used for that default, and an additional label with the same name will be ignored. Overall, this case is pretty thorny so further adjustments might be warranted. Fixes: #8881 Change-Id: Ie939b1470cb2e824717384be65f4cd8edd619942
* | Add new script to sync test files adding future annotationFederico Caselli2022-11-263-11/+31
|/ | | | | | | | | | | Create a new test file test_tm_future_annotations_sync.py that's obtained from test_tm_future_annotations.py by using the new script sync_test_files. This files includes the ``from __future__ import annotations`` It also turns out we had some bugs in there and we can also support some additional typing things Change-Id: Iac005df206d45a55345d9d88d67a80ce799d449f
* add "merge" to viewonly cascades; propagate NO_RAISE when mergingMike Bayer2022-11-244-4/+26
| | | | | | | | | | | | | | | | | | | | | | | | | Fixed bug where :meth:`_orm.Session.merge` would fail to preserve the current loaded contents of relationship attributes that were indicated with the :paramref:`_orm.relationship.viewonly` parameter, thus defeating strategies that use :meth:`_orm.Session.merge` to pull fully loaded objects from caches and other similar techniques. In a related change, fixed issue where an object that contains a loaded relationship that was nonetheless configured as ``lazy='raise'`` on the mapping would fail when passed to :meth:`_orm.Session.merge`; checks for "raise" are now suspended within the merge process assuming the :paramref:`_orm.Session.merge.load` parameter remains at its default of ``True``. Overall, this is a behavioral adjustment to a change introduced in the 1.4 series as of :ticket:`4994`, which took "merge" out of the set of cascades applied by default to "viewonly" relationships. As "viewonly" relationships aren't persisted under any circumstances, allowing their contents to transfer during "merge" does not impact the persistence behavior of the target object. This allows :meth:`_orm.Session.merge` to correctly suit one of its use cases, that of adding objects to a :class:`.Session` that were loaded elsewhere, often for the purposes of restoring from a cache. Fixes: #8862 Change-Id: I8731c7810460e6a71f8bf5e8ded59142b9b02956
* Merge "ensure implicit_returning is checked on a Table instance" into mainmike bayer2022-11-221-1/+1
|\
| * ensure implicit_returning is checked on a Table instanceMike Bayer2022-11-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixed regression where flushing a mapped class that's mapped against a subquery, such as a direct mapping or some forms of concrete table inheritance, would fail if the :paramref:`_orm.Mapper.eager_defaults` parameter were used. mapper.local_table can still be a non-table instance. correct the check first added in 466ed5b53a3. Fixes: #8812 Change-Id: I1bb2b83c31b910fbd96fcd3ac43e789b657aebf7
* | Merge "fix optionalized forms for dict[]" into mainmike bayer2022-11-222-6/+23
|\ \
| * | fix optionalized forms for dict[]Mike Bayer2022-11-222-6/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed a suite of issues involving :class:`.Mapped` use with dictionary types, such as ``Mapped[dict[str, str] | None]``, would not be correctly interpreted in Declarative ORM mappings. Support to correctly "de-optionalize" this type including for lookup in type_annotation_map has been fixed. Fixes: #8777 Change-Id: Iaba90791dea341d00eaff788d40b0a4e48dab02e
* | | Merge "Fix inferred type of async_sessionmaker" into mainmike bayer2022-11-211-0/+27
|\ \ \
| * | | Fix inferred type of async_sessionmakerSam Bull2022-11-211-0/+27
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Improved the typing for :class:`.sessionmaker` and :class:`.asyncsessionmaker`, so that the default type of their return value will be :class:`.Session` or :class:`.AsyncSession`, without the need to type this explicitly. Previously, Mypy would not automaticaly infer these return types from its generic base. As part of this change, arguments for :class:`.Session`, :class:`.AsyncSession`, :class:`.sessionmaker` and :class:`.asyncsessionmaker` beyond the initial "bind" argument have been made keyword-only, which includes parameters that have always been documented as keyword arguments, such as :paramref:`.Session.autoflush`, :paramref:`.Session.class_`, etc. Pull request courtesy Sam Bull. Closes: #8842 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8842 Pull-request-sha: fa6d1a8468e98b40e12f82ed7ddaddc1fde060ac Change-Id: Iaaabc4572a87489d61617d970f62b9b50db4fac7
* | | add common base class for all SQL col expression objectsMike Bayer2022-11-215-7/+47
|/ / | | | | | | | | | | | | | | | | | | | | Added a new type :class:`.SQLColumnExpression` which may be indicated in user code to represent any SQL column oriented expression, including both those based on :class:`.ColumnElement` as well as on ORM :class:`.QueryableAttribute`. This type is a real class, not an alias, so can also be used as the foundation for other objects. Fixes: #8847 Change-Id: I3161bdff1c9f447793fce87864e1774a90cd4146
* | Try running pyupgrade on the codeFederico Caselli2022-11-1618-187/+140
|/ | | | | | | | command run is "pyupgrade --py37-plus --keep-runtime-typing --keep-percent-format <files...>" pyupgrade will change assert_ to assertTrue. That was reverted since assertTrue does not exists in sqlalchemy fixtures Change-Id: Ie1ed2675c7b11d893d78e028aad0d1576baebb55
* Merge "don't invoke fromclause.c when creating an annotated" into mainmike bayer2022-11-161-1/+6
|\
| * don't invoke fromclause.c when creating an annotatedMike Bayer2022-11-151-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ``aliased()`` constructor calls upon ``__clause_element__()``, which internally annotates a ``FromClause``, like a subquery. This became expensive as ``AnnotatedFromClause`` has for many years called upon ``element.c`` so that the full ``.c`` collection is transferred to the Annotated. Taking this out proved to be challenging. A straight remove seemed to not break any tests except for the one that tested the exact condition. Nevertheless this seemed "spooky" so I instead moved the get of ``.c`` to be in a memoized proxy method. However, that then exposed a recursion issue related to loader_criteria; so the source of that behavior, which was an accidental behavioral artifact, is now made into an explcicit option that loader_criteria uses directly. The accidental behavioral artifact in question is still kind of strange since I was not able to fully trace out how it works, but the end result is that fixing the artifact to be "correct" causes loader_criteria, within the particular test for #7491, creates a select/ subquery structure with a cycle in it, so compilation fails with recursion overflow. The "solution" is to cause the artifact to occur in this case, which is that the ``AnnotatedFromClause`` will have a different ``.c`` collection than its element, which is a subquery. It's not totally clear how a cycle is generated when this is not done. This is commit one of two, which goes through some hoops to make essentially a one-line change. The next commit will rework ColumnCollection to optimize the corresponding_column() method significantly. Fixes: #8796 Change-Id: Id58ae6554db62139462c11a8be7313a3677456ad
* | Fix relationship.order_by typingBryan Forbes2022-11-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes: #8776 ### Checklist This pull request is: - [ ] A documentation / typographical error fix - Good to go, no issue or tests are needed - [x] A short code fix - please include the issue number, and create an issue if none exists, which must include a complete example of the issue. one line code fixes without an issue and demonstration will not be accepted. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. one line code fixes without tests will not be accepted. - [ ] A new feature implementation - please include the issue number, and create an issue if none exists, which must include a complete example of how the feature would look. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. Closes: #8779 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8779 Pull-request-sha: 2bc64555a1ab662881fdfd1caaabd9d21fbdf531 Change-Id: I52fe6db5ba954a6039836b45f0e89ad96049df03
* | Explicitly state what happens if `order_by` is called more than once. (#8791)Eitan Mosenkis2022-11-141-3/+4
|/ | | | | | | * Explicitly state what happens if `order_by` is called more than once. The existing docs cover how to clear existing `order_by` clauses but don't actually describe the behavior of calling `order_by` multiple times with different clauses. * Also update Select.order_by.
* work around Python 3.11 IntEnum issue; update FastIntFlagMike Bayer2022-11-102-11/+6
| | | | | | | | | | | | | | | | | in [1], Python 3.11 seems to have changed the behavior of IntEnum. We didn't notice this because we have our own workaround class already, but typing did. Ensure we remain compatible with IntFlag. This change also modifies FastIntFlag to no longer use global symbols; this is unnecessary as we assign FastIntFlag members explicitly. Use of ``symbol()`` should probably be phased out. [1] https://github.com/python/cpython/issues/99304 Fixes: #8783 Change-Id: I8ae2e871ff1467ae5ca1f63e66b5dae45d4a6c93
* try to support mypy 0.990Mike Bayer2022-11-092-4/+6
| | | | | | | | | | | mypy introduces a crash we need to work around, also some new rules. It also has either a behavioral change regarding how output is rendered in relationship to files being within sys.path or not, so work around that for test_mypy_plugin_py3k.py References: https://github.com/python/mypy/issues/14027 Change-Id: I689c7fe27dc52abee932de9e0fb23b2a2eba76fa
* Merge "support renamed symbols in annotation scans" into mainmike bayer2022-11-042-24/+87
|\
| * support renamed symbols in annotation scansMike Bayer2022-11-042-24/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added support in ORM declarative annotations for class names specified for :func:`_orm.relationship`, as well as the name of the :class:`_orm.Mapped` symbol itself, to be different names than their direct class name, to support scenarios such as where :class:`_orm.Mapped` is imported as ``from sqlalchemy.orm import Mapped as M``, or where related class names are imported with an alternate name in a similar fashion. Additionally, a target class name given as the lead argument for :func:`_orm.relationship` will always supersede the name given in the left hand annotation, so that otherwise un-importable names that also don't match the class name can still be used in annotations. Fixes: #8759 Change-Id: I74a00de7e1a45bf62dad50fd385bb75cf343f9f3
* | resolve synonyms in dictionary form of Session.get()Mike Bayer2022-11-042-1/+34
|/ | | | | | | | | Improved "dictionary mode" for :meth:`_orm.Session.get` so that synonym names which refer to primary key attribute names may be indicated in the named dictionary. Fixes: #8753 Change-Id: I56112564a5c23b51b26e01c64087cbf4399cd951
* Support result.close() for all iterator patternsMike Bayer2022-11-031-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change contains new features for 2.0 only as well as some behaviors that will be backported to 1.4. For 1.4 and 2.0: Fixed issue where the underlying DBAPI cursor would not be closed when using :class:`_orm.Query` with :meth:`_orm.Query.yield_per` and direct iteration, if a user-defined exception case were raised within the iteration process, interrupting the iterator. This would lead to the usual MySQL-related issues with server side cursors out of sync. For 1.4 only: A similar scenario can occur when using :term:`2.x` executions with direct use of :class:`.Result`, in that case the end-user code has access to the :class:`.Result` itself and should call :meth:`.Result.close` directly. Version 2.0 will feature context-manager calling patterns to address this use case. However within the 1.4 scope, ensured that ``.close()`` methods are available on all :class:`.Result` implementations including :class:`.ScalarResult`, :class:`.MappingResult`. For 2.0 only: To better support the use case of iterating :class:`.Result` and :class:`.AsyncResult` objects where user-defined exceptions may interrupt the iteration, both objects as well as variants such as :class:`.ScalarResult`, :class:`.MappingResult`, :class:`.AsyncScalarResult`, :class:`.AsyncMappingResult` now support context manager usage, where the result will be closed at the end of iteration. Corrected various typing issues within the engine and async engine packages. Fixes: #8710 Change-Id: I3166328bfd3900957eb33cbf1061d0495c9df670
* Improve typings of execution optionsFederico Caselli2022-11-026-46/+96
| | | | | Fixes: #8605 Change-Id: I4aec83b9f321462427c3f4ac941c3b272255c088
* evaluate types in terms of the class in which they appearMike Bayer2022-10-316-22/+81
| | | | | | | | | | | Fixed issues within the declarative typing resolver (i.e. which resolves ``ForwardRef`` objects) where types that were declared for columns in one particular source file would raise ``NameError`` when the ultimate mapped class were in another source file. The types are now resolved in terms of the module for each class in which the types are used. Fixes: #8742 Change-Id: I236f94484ea79d47392a6201e671eeb89c305fd8
* fix test for same mapper to use "isa"Mike Bayer2022-10-301-3/+7
| | | | | | | | | Fixed issue in joined eager loading where an assertion fail would occur with a particular combination of outer/inner joined eager loads in conjunction with an inherited subclass mapper as the middle target. Fixes: #8738 Change-Id: I4909e7518302cbb82046e0425abbbdc8eb1c0146
* ensure _ORMJoin transfers parententity from left sideMike Bayer2022-10-283-2/+30
| | | | | | | | | | | | | | | | | | Fixed bug involving :class:`.Select` constructs which used a combination of :meth:`.Select.select_from` with an ORM entity followed by :meth:`.Select.join` against the entity sent in :meth:`.Select.select_from`, as well as using plain :meth:`.Select.join_from`, which when combined with a columns clause that didn't explicitly include that entity would then cause "automatic WHERE criteria" features such as the IN expression required for a single-table inheritance subclass, as well as the criteria set up by the :func:`_orm.with_loader_criteria` option, to not be rendered for that entity. The correct entity is now transferred to the :class:`.Join` object that's generated internally, so that the criteria against the left side entity is correctly added. Fixes: #8721 Change-Id: I8266430063e2c72071b7262fdd5ec5079fbcba3e
* ensure inherited mapper attrs not interpreted as plain dataclass fieldsMike Bayer2022-10-262-10/+33
| | | | | | | | | Fixed issue in new dataclass mapping feature where a column declared on the decalrative base / abstract base / mixin would leak into the constructor for an inheriting subclass under some circumstances. Fixes: #8718 Change-Id: Ic519acf239e2f80541516f10995991cbbbed00bd
* Merge "reconcile Mapper properties ordering against mapped Table" into mainmike bayer2022-10-251-73/+184
|\
| * reconcile Mapper properties ordering against mapped TableMike Bayer2022-10-251-73/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changed a fundamental configuration behavior of :class:`.Mapper`, where :class:`_schema.Column` objects that are explicitly present in the :paramref:`_orm.Mapper.properties` dictionary, either directly or enclosed within a mapper property object, will now be mapped within the order of how they appear within the mapped :class:`.Table` (or other selectable) itself (assuming they are in fact part of that table's list of columns), thereby maintaining the same order of columns in the mapped selectable as is instrumented on the mapped class, as well as what renders in an ORM SELECT statement for that mapper. Previously (where "previously" means since version 0.0.1), :class:`.Column` objects in the :paramref:`_orm.Mapper.properties` dictionary would always be mapped first, ahead of when the other columns in the mapped :class:`.Table` would be mapped, causing a discrepancy in the order in which the mapper would assign attributes to the mapped class as well as the order in which they would render in statements. The change most prominently takes place in the way that Declarative assigns declared columns to the :class:`.Mapper`, specifically how :class:`.Column` (or :func:`_orm.mapped_column`) objects are handled when they have a DDL name that is explicitly different from the mapped attribute name, as well as when constructs such as :func:`_orm.deferred` etc. are used. The new behavior will see the column ordering within the mapped :class:`.Table` being the same order in which the attributes are mapped onto the class, assigned within the :class:`.Mapper` itself, and rendered in ORM statements such as SELECT statements, independent of how the :class:`_schema.Column` was configured against the :class:`.Mapper`. Fixes: #8705 Change-Id: I95cc05061a97fe6b1654bab70e2f6da30f8f3bd3
* | raise for non-Load opt passed to options()Mike Bayer2022-10-251-1/+10
| | | | | | | | | | | | | | | | | | | | | | Fixed the exception that's raised when the :func:`_orm.with_loader_criteria` option is attempted to be used within a specific loader path, like in loader.options(). :func:`_orm.with_loader_criteria` is only intended to be used at the top level. Fixes: #8711 Change-Id: Iaa7b13956b808761e618a6be6406e5c82df1c65c
* | Merge "skip ad-hoc properties within subclass_load_via_in" into mainmike bayer2022-10-241-2/+11
|\ \ | |/ |/|
| * skip ad-hoc properties within subclass_load_via_inMike Bayer2022-10-231-2/+11
| | | | | | | | | | | | | | | | | | | | Fixed issue where "selectin_polymorphic" loading for inheritance mappers would not function correctly if the :param:`_orm.Mapper.polymorphic_on` parameter referred to a SQL expression that was not directly mapped on the class. Fixes: #8704 Change-Id: I1b6be2650895fd18d2c804f6ba96de966d11041a
* | DeclarativeBase ``__table__`` annotation is not optionalFederico Caselli2022-10-221-1/+1
|/ | | | Change-Id: I92bfc0cf58fa2e6f9d7e8055f1a337ec806c1410
* allow legacy forms with __allow_unmapped__Mike Bayer2022-10-212-41/+43
| | | | | | | | | | | | | | | Improved support for legacy 1.4 mappings that use annotations which don't include ``Mapped[]``, by ensuring the ``__allow_unmapped__`` attribute can be used to allow such legacy annotations to pass through Annotated Declarative without raising an error and without being interpreted in an ORM runtime context. Additionally improved the error message generated when this condition is detected, and added more documentation for how this situation should be handled. Unfortunately the 1.4 WARN_SQLALCHEMY_20 migration warning cannot detect this particular configurational issue at runtime with its current architecture. Fixes: #8692 Change-Id: I5c642bcc1ebb7816f9470ec9bb0951550b6d55f1
* collect annotation earlier for mapped_column presentMike Bayer2022-10-201-3/+15
| | | | | | | | | | | | | | | | | | | | Fixed issue with new dataclass mapping feature where arguments passed to the dataclasses API could sometimes be mis-ordered when dealing with mixins that override :func:`_orm.mapped_column` declarations, leading to initializer problems. the change made here is specific to the test case given which regards mapped_column() most specifically. cases that involve relationship() etc. are not tested here, however mapped_column() is the only attribute that's implicit without an instance given on the right side, and is also most common for mixins. not clear if there are more issues in this area, however it appears that we need only adjust the order in which we accommodate grabbing the annotations in order to affect how dataclasses sees the class; that is, we have control over ``__annotations__`` here so dont have to worry about ``cls.__dict__``. Fixes: #8688 Change-Id: I808c86f23d73aa47cd910ae01c3e07093d469fdc
* Merge "Improve typing of DeclarativeBase" into mainmike bayer2022-10-202-1/+7
|\
| * Improve typing of DeclarativeBaseFederico Caselli2022-10-192-1/+7
| | | | | | | | | | | | | | Also allow mapped columns inside indexes, unique cosntraints, primary key constriant Fixes: #8645 Change-Id: If37ab85ead0fbd1125cd6329c2f01a031777b081
* | more many-to-one typingMike Bayer2022-10-192-1/+4
|/ | | | | | | | | | | | | | | | | | since we are typing centric, note this configuration as we have just supported in #8668. Note also I am just taking "backref" out of the basic version of the docs here totally, this doc is already a lot to read / take in without making it even more confusing; backref still has an entirely dedicated docs page which can have all the additional behaviors of backref() described. Additionally, get other "optional" forms to work including ``cls | None`` and ``Union[cls, None]``. Fixes: #8668 Change-Id: I2b026f496a1710ddebfb4aa6cf8459b4892cbc54
* de-optionalize union types to support Optional for m2oMike Bayer2022-10-191-6/+10
| | | | | | | | | Fixed bug in new ORM typed declarative mappings where we did not include the ability to use ``Optional[]`` in the type annotation for a many-to-one relationship, even though this is common. Fixes: #8668 Change-Id: Idaf0846e49cc12095394b99ad6fe678735cf9242
* call super().__init_subclass__(); support GenericAliasMike Bayer2022-10-192-1/+14
| | | | | | | | | | | | | Improved the :class:`.DeclarativeBase` class so that when combined with other mixins like :class:`.MappedAsDataclass`, the order of the classes may be in either order. Added support for mapped classes that are also ``Generic`` subclasses, to be specified as a ``GenericAlias`` object (e.g. ``MyClass[str]``) within statements and calls to :func:`_sa.inspect`. Fixes: #8665 Change-Id: I03063a28b0438a44b9e028fd9d45e8ce08bd18c4
* simplify unmapped col eval fallbackMike Bayer2022-10-172-53/+47
| | | | | | | | | | | | | Removed the warning that emits when using ORM-enabled update/delete regarding evaluation of columns by name, first added in :ticket:`4073`; this warning actually covers up a scenario that otherwise could populate the wrong Python value for an ORM mapped attribute depending on what the actual column is, so this deprecated case is removed. In 2.0, ORM enabled update/delete uses "auto" for "synchronize_session", which should do the right thing automatically for any given UPDATE expression. Fixes: #8656 Change-Id: Idb8b4a86d3caed89f69cde1607886face103cf6a
* repair type qualify in _ServerDefaultType; other pyright tweaksMike Bayer2022-10-162-5/+5
| | | | | | | | | | | | | | | | | as we haven't done full pylance / pyright strict typing internally, some of the things pyright reports on specifically will leak out into user code, such as this mapped_column() issue. So we will have to look more closely at pyright strict mode going forward for the release. Fixed typing issue where pylance strict mode would report "partially unknown" datatype for the :func:`_orm.mapped_column` construct. Also repaired a trailing comma and pyright complaining about overloads for orm.composite. Fixes: #8644 Change-Id: Ia48dc5dbd56bbceeacee4f0daf9810bfdea3bee3
* Merge "implement autobegin=False option" into mainmike bayer2022-10-123-51/+127
|\
View Lorry Controller Status