summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/orm/decl_base.py
Commit message (Collapse)AuthorAgeFilesLines
* allow column named twice warning to take effectMike Bayer2023-05-091-1/+5
| | | | | | | | | | | Fixed issue in :func:`_orm.mapped_column` construct where the correct warning for "column X named directly multiple times" would not be emitted when ORM mapped attributes referred to the same :class:`_schema.Column`, if the :func:`_orm.mapped_column` construct were involved, raising an internal assertion instead. Fixes: #9630 Change-Id: I5d9dfaaa225aefb487c9cd981ba3ad78507bb577
* add deterministic imv returning ordering using sentinel columnsMike Bayer2023-04-211-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Repaired a major shortcoming which was identified in the :ref:`engine_insertmanyvalues` performance optimization feature first introduced in the 2.0 series. This was a continuation of the change in 2.0.9 which disabled the SQL Server version of the feature due to a reliance in the ORM on apparent row ordering that is not guaranteed to take place. The fix applies new logic to all "insertmanyvalues" operations, which takes effect when a new parameter :paramref:`_dml.Insert.returning.sort_by_parameter_order` on the :meth:`_dml.Insert.returning` or :meth:`_dml.UpdateBase.return_defaults` methods, that through a combination of alternate SQL forms, direct correspondence of client side parameters, and in some cases downgrading to running row-at-a-time, will apply sorting to each batch of returned rows using correspondence to primary key or other unique values in each row which can be correlated to the input data. Performance impact is expected to be minimal as nearly all common primary key scenarios are suitable for parameter-ordered batching to be achieved for all backends other than SQLite, while "row-at-a-time" mode operates with a bare minimum of Python overhead compared to the very heavyweight approaches used in the 1.x series. For SQLite, there is no difference in performance when "row-at-a-time" mode is used. It's anticipated that with an efficient "row-at-a-time" INSERT with RETURNING batching capability, the "insertmanyvalues" feature can be later be more easily generalized to third party backends that include RETURNING support but not necessarily easy ways to guarantee a correspondence with parameter order. Fixes: #9618 References: #9603 Change-Id: I1d79353f5f19638f752936ba1c35e4dc235a8b7c
* include declared_directive as a declared_attrMike Bayer2023-04-101-2/+2
| | | | | | | | | | | Fixed issue where the :meth:`_orm.declared_attr.directive` modifier was not correctly honored for subclasses when applied to the ``__mapper_args__`` special method name, as opposed to direct use of :class:`_orm.declared_attr`. The two constructs should have identical runtime behaviors. Fixes: #9625 Change-Id: I0dfe9e73bb45f70dbebc8e94ce280ad3b52e867f
* Wrap dataclass exceptions clarifying originFederico Caselli2023-03-311-0/+8
| | | | | | | | | | | | | Exceptions such as ``TypeError`` and ``ValueError`` raised by Python dataclasses when making use of the :class:`_orm.MappedAsDataclass` mixin class or :meth:`_orm.registry.mapped_as_dataclass` decorator are now wrapped within an :class:`.InvalidRequestError` wrapper along with informative context about the error message, referring to the Python dataclasses documentation as the authoritative source of background information on the cause of the exception. Fixes: #9563 Change-Id: I25652485b91c4ee8cf112b91aae8f9041061a8bd
* Merge "skip anno-only mixin columns that are overridden on subclasses" into mainmike bayer2023-03-311-2/+16
|\
| * skip anno-only mixin columns that are overridden on subclassesMike Bayer2023-03-301-2/+16
| | | | | | | | | | | | | | | | | | | | | | Fixed issue where an annotation-only :class:`_orm.Mapped` directive could not be used in a Declarative mixin class, without that attribute attempting to take effect for single- or joined-inheritance subclasses of mapped classes that had already mapped that attribute on a superclass, producing conflicting column errors and/or warnings. Fixes: #9564 Change-Id: I0f92be2ae98a8c45afce3e06d0a7cc61c19a96f4
* | warn for DC mixin / abstract fields that are not on a dataclassMike Bayer2023-03-301-11/+52
| | | | | | | | | | | | | | | | | | | | | | | | Fields that are declared on Declarative Mixins and then combined with classes that make use of :class:`_orm.MappedAsDataclass`, where those mixin fields are not themselves part of a dataclass, now emit a deprecation warning as these fields will be ignored in a future release, as Python dataclasses behavior is to ignore these fields. Type checkers will not see these fields under pep-681. Fixes: #9350 Change-Id: Ie0a0ac0f0bb58d1c2aae13b4a8dcd0439a4f5477
* | warn for all unmapped expressionsMike Bayer2023-03-241-3/+6
|/ | | | | | | | | | | | | | Expanded the warning emitted when a plain :func:`_sql.column` object is present in a Declarative mapping to include any arbitrary SQL expression that is not declared within an appropriate property type such as :func:`_orm.column_property`, :func:`_orm.deferred`, etc. These attributes are otherwise not mapped at all and remain unchanged within the class dictionary. As it seems likely that such an expression is usually not what's intended, this case now warns for all such otherwise ignored expressions, rather than just the :func:`_sql.column` case. Fixes: #9537 Change-Id: Ic4ca7a071a28adf4ea8680690025d927522a0805
* apply a fixed locals w/ Mapped to all de-stringifyMike Bayer2023-02-261-1/+1
| | | | | | | | | | | | | | | Continued the fix for :ticket:`8853`, allowing the :class:`_orm.Mapped` name to be fully qualified regardless of whether or not ``from __annotations__ import future`` were present. This issue first fixed in 2.0.0b3 confirmed that this case worked via the test suite, however the test suite apparently was not testing the behavior for the name ``Mapped`` not being locally present at all; string resolution has been updated to ensure the ``Mapped`` symbol is locatable as applies to how the ORM uses these functions. Fixes: #8853 Fixes: #9335 Change-Id: Id82d09aee906165a4d77c7da6a0b4177dd675c10
* Allow custom sorting of column in the ORM.Federico Caselli2023-02-161-5/+17
| | | | | | | | | | | | | | | To accommodate a change in column ordering used by ORM Declarative in SQLAlchemy 2.0, a new parameter :paramref:`_orm.mapped_column.sort_order` has been added that can be used to control the order of the columns defined in the table by the ORM, for common use cases such as mixins with primary key columns that should appear first in tables. The change notes at :ref:`change_9297` illustrate the default change in ordering behavior (which is part of all SQLAlchemy 2.0 releases) as well as use of the :paramref:`_orm.mapped_column.sort_order` to control column ordering when using mixins and multiple classes (new in 2.0.4). Fixes: #9297 Change-Id: Ic7163d64efdc0eccb53d6ae0dd89ec83427fb675
* add dataclasses callable and apply annotations more strictlyMike Bayer2023-02-161-12/+69
| | | | | | | | | | | | | | | | | Added new parameter ``dataclasses_callable`` to both the :class:`_orm.MappedAsDataclass` class as well as the :meth:`_orm.registry.mapped_as_dataclass` method which allows an alternative callable to Python ``dataclasses.dataclass`` to be used in order to produce dataclasses. The use case here is to drop in Pydantic's dataclass function instead. Adjustments have been made to the mixin support added for :ticket:`9179` in version 2.0.1 so that the ``__annotations__`` collection of the mixin is rewritten to not include the :class:`_orm.Mapped` container, in the same way as occurs with mapped classes, so that the Pydantic dataclasses constructor is not exposed to unknown types. Fixes: #9266 Change-Id: Ia0fab6f20b93a5cb853799dcf1b70a0386837c14
* Merge "coerce elements in mapper.primary_key, process in __mapper_args__" ↵mike bayer2023-02-051-0/+6
|\ | | | | | | into main
| * coerce elements in mapper.primary_key, process in __mapper_args__Mike Bayer2023-02-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Repaired ORM Declarative mappings to allow for the :paramref:`_orm.Mapper.primary_key` parameter to be specified within ``__mapper_args__`` when using :func:`_orm.mapped_column`. Despite this usage being directly in the 2.0 documentation, the :class:`_orm.Mapper` was not accepting the :func:`_orm.mapped_column` construct in this context. Ths feature was already working for the :paramref:`_orm.Mapper.version_id_col` and :paramref:`_orm.Mapper.polymorphic_on` parameters. As part of this change, the ``__mapper_args__`` attribute may be specified without using :func:`_orm.declared_attr` on a non-mapped mixin class, including a ``"primary_key"`` entry that refers to :class:`_schema.Column` or :func:`_orm.mapped_column` objects locally present on the mixin; Declarative will also translate these columns into the correct ones for a particular mapped class. This again was working already for the :paramref:`_orm.Mapper.version_id_col` and :paramref:`_orm.Mapper.polymorphic_on` parameters. Additionally, elements within ``"primary_key"`` may be indicated as string names of existing mapped properties. Fixes: #9240 Change-Id: Ie2000273289fa23e0af21ef9c6feb3962a8b848c
* | Merge "Guard against wrong dataclass mapping" into mainFederico Caselli2023-02-051-0/+11
|\ \
| * | Guard against wrong dataclass mappingFederico Caselli2023-02-051-0/+11
| |/ | | | | | | | | | | | | | | Ensure that the decorator style @registry.mapped_as_dataclass and MappedAsDataclass are not mixed. Fixes: #9211 Change-Id: I5cd94cae862122e4f627d0d051495b3789cf6de5
* | disallow ORM instrumented attributes from reaching dataclassesMike Bayer2023-02-031-0/+11
|/ | | | | | | | | | | More adjustments to ORM Declarative Dataclasses mappings, building on the improved support for mixins with dataclasses added in 2.0.1 via :ticket:`9179`, where a combination of using mixins plus ORM inheritance would mis-classify fields in some cases leading to their dataclass arguments such as ``init=False`` being lost. Fixes: #9226 Change-Id: Ia36f413e23e91dfbdb900f5ff3f8cdd3d5847064
* Add support for typing.Literal in MappedFrederik Aalund2023-01-311-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added support for :pep:`586` ``Literal`` to be used in the :paramref:`_orm.registry.type_annotation_map` as well as within :class:`.Mapped` constructs. To use custom types such as these, they must appear explicitly within the :paramref:`_orm.registry.type_annotation_map` to be mapped. Pull request courtesy Frederik Aalund. As part of this change, the support for :class:`.sqltypes.Enum` in the :paramref:`_orm.registry.type_annotation_map` has been expanded to include support for ``Literal[]`` types consisting of string values to be used, in addition to ``enum.Enum`` datatypes. If a ``Literal[]`` datatype is used within ``Mapped[]`` that is not linked in :paramref:`_orm.registry.type_annotation_map` to a specific datatype, a :class:`.sqltypes.Enum` will be used by default. Fixed issue involving the use of :class:`.sqltypes.Enum` within the :paramref:`_orm.registry.type_annotation_map` where the :paramref:`_sqltypes.Enum.native_enum` parameter would not be correctly copied to the mapped column datatype, if it were overridden as stated in the documentation to set this parameter to False. Fixes: #9187 Fixes: #9200 Closes: #9191 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9191 Pull-request-sha: 7d13f705307bf62560fc831f6f049a425d411374 Change-Id: Ife3ba2655f4897f806d6a9cf0041c69fd4f39e9d
* MappedAsDataclass applies @dataclasses.dataclass unconditionallyMike Bayer2023-01-301-2/+10
| | | | | | | | | | | | | | | | | | | | | | When using the :class:`.MappedAsDataclass` superclass, all classes within the hierarchy that are subclasses of this class will now be run through the ``@dataclasses.dataclass`` function whether or not they are actually mapped, so that non-ORM fields declared on non-mapped classes within the hierarchy will be used when mapped subclasses are turned into dataclasses. This behavior applies both to intermediary classes mapped with ``__abstract__ = True`` as well as to the user-defined declarative base itself, assuming :class:`.MappedAsDataclass` is present as a superclass for these classes. This allows non-mapped attributes such as ``InitVar`` declarations on superclasses to be used, without the need to run the ``@dataclasses.dataclass`` decorator explicitly on each non-mapped class. The new behavior is considered as correct as this is what the :pep:`681` implementation expects when using a superclass to indicate dataclass behavior. Fixes: #9179 Change-Id: Ia01fa9806a27f7c1121bf7eaddf2847cf6dc5313
* Add public protocol for mapped classFederico Caselli2023-01-251-28/+51
| | | | | Fixes: #8624 Change-Id: Ia7a66ae9ba534ed7152f95dfd0f7d05b9d00165a
* happy new year 2023Mike Bayer2023-01-031-1/+1
| | | | Change-Id: I625af65b3fb1815b1af17dc2ef47dd697fdc3fb1
* remove __allow_unmapped__ requirement from dataclassesMike Bayer2022-12-191-1/+1
| | | | | | | | | | | | | Removed the requirement that the ``__allow_unmapped__`` attribute be used on Declarative Dataclass Mapped class when non-``Mapped[]`` annotations are detected; previously, an error message that was intended to support legacy ORM typed mappings would be raised, which additionally did not mention correct patterns to use with Dataclasses specifically. This error message is now no longer raised if :meth:`_orm.registry.mapped_as_dataclass` or :class:`_orm.MappedAsDataclass` is used. Fixes: #8973 Change-Id: I887afcc2da83dd904444bcb97f31e695b9f8b443
* add new pattern for single inh column overrideMike Bayer2022-11-301-31/+53
| | | | | | | | | | | | | | 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
* annotated / DC forms for association proxyMike Bayer2022-11-291-36/+66
| | | | | | | | | | | | | | | | | | | | | | | | 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
* identify unresolvable Mapped typesMike Bayer2022-11-281-50/+79
| | | | | | | | | | | | | | | | | 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
* Add new script to sync test files adding future annotationFederico Caselli2022-11-261-0/+11
| | | | | | | | | | | 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
* Try running pyupgrade on the codeFederico Caselli2022-11-161-13/+9
| | | | | | | | 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
* evaluate types in terms of the class in which they appearMike Bayer2022-10-311-10/+36
| | | | | | | | | | | 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
* ensure inherited mapper attrs not interpreted as plain dataclass fieldsMike Bayer2022-10-261-9/+14
| | | | | | | | | 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
* allow legacy forms with __allow_unmapped__Mike Bayer2022-10-211-9/+27
| | | | | | | | | | | | | | | 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
* implement write-only colletions, typing for dynamicMike Bayer2022-10-061-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For 2.0, we provide a truly "larger than memory collection" implementation, a write-only collection that will never under any circumstances implicitly load the entire collection, even during flush. This is essentially a much more "strict" version of the "dynamic" loader, which in fact has a lot of scenarios that it loads the full backing collection into memory, mostly defeating its purpose. Typing constructs are added that support both the new feature WriteOnlyMapping as well as the legacy feature DynamicMapping. These have been integrated with "annotion based mapping" so that relationship() uses these annotations to configure the loader strategy as well. additional changes: * the docs triggered a conflict in hybrid's "transformers" section, this section is hard-coded to Query using a pattern that doesnt seem to have any use and isn't part of the current select() interface, so just removed this section * As the docs for WriteOnlyMapping are very long, collections.rst is broken up into two pages now. Fixes: #6229 Fixes: #7123 Change-Id: I6929f3da6e441cad92285e7309030a9bac4e429d
* reorganize Mapped[] super outside of MapperPropertyMike Bayer2022-10-051-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | We made all the MapperProperty classes a subclass of Mapped[] to allow declarative mappings to name Mapped[] on the left side. this was cheating a bit because MapperProperty is not actually a descriptor, and the mapping process replaces the object with InstrumentedAttribute at mapping time, which is the actual Mapped[] descriptor. But now in I6929f3da6e441cad92285e7309030a9bac4e429d we are considering making the "cheating" a little more extensive by putting DynamicMapped / WriteOnlyMapped in Relationship's hierarchy, which need a flat out "type: ignore" to work. Instead of pushing more cheats into the core classes, move out the "Declarative"-facing versions of these classes to be typing only: Relationship, Composite, Synonym, and MappedSQLExpression added for ColumnProperty. Keep the internals expressed on the old names, RelationshipProperty, CompositeProperty, SynonymProperty, ColumnProprerty, which will remain "pure" with fully correct typing. then have the typing only endpoints be where the "cheating" and "type: ignores" have to happen, so that these are more or less slightly better forms of "Any". Change-Id: Ied7cc11196c9204da6851f49593d1b1fd2ef8ad8
* Support kw_only and match_args in dataclass mappingFederico Caselli2022-08-041-14/+14
| | | | | Fixes: #8346 Change-Id: I964629e3bd25221bf6df6ab31c59b3ce1983cd9a
* make anno-only Mapped[] column available for mixinsMike Bayer2022-07-151-22/+26
| | | | | | | | | | | | | | Documentation is relying on the recently improved behavior of produce_column_copies() to make sure everything is available on cls for a declared_attr. therefore for anno-only attribute, we also need to generate the mapped_column() up front before scan is called. noticed in pylance, allow @declared_attr to recognize @classmethod also which allows letting typing tools know something is explicitly a classmethod Change-Id: I07ff1a642a75679f685914a33c674807929f4918
* produce column copies up the whole hierarchy firstMike Bayer2022-06-291-4/+37
| | | | | | | | | | | | | | Fixed issue where a hierarchy of classes set up as an abstract or mixin declarative classes could not declare standalone columns on a superclass that would then be copied correctly to a :class:`_orm.declared_attr` callable that wanted to make use of them on a descendant class. Originally it looked like this would produce an ordering change, however an adjustment to the flow for produce_column_copies has avoided that for now. Fixes: #8190 Change-Id: I4e2ee74edb110793eb42691c3e4a0e0535fba7e9
* new features for pep 593 AnnotatedMike Bayer2022-06-151-7/+24
| | | | | | | | | | | | | | | * extract the inner type from Annotated when the outer type isn't present in the type map, to allow for arbitrary Annotated * allow _IntrospectsAnnotations objects to be directly present in an Annotated and resolve the mapper property from that. Currently implemented for mapped_column(), with message for others. Can work for composite() and likely some relationship() as well at some point References: https://twitter.com/zzzeek/status/1536693554621341697 and replies Change-Id: I04657050a8785f194bf8f63291faf3475af88781
* some typing fixesMike Bayer2022-06-031-5/+41
| | | | | | | | | | | | | | | | | | | | | | * ClassVar for decl fields, add __tablename__ * dataclasses require annotations for all fields. For us, if no annotation, then skip that field as part of what is considered to be a "dataclass", as this matches the behavior of pyright right now. We could alternatively raise on this use, which is what dataclasses does. we should ask the pep people * plain field that's just "str", "int", etc., with no value. Disallow it unless __allow_unmapped__ is set. If field has dataclasses.field, Column, None, a value etc, it goes through, and when using dataclasses mixin all such fields are considered for the dataclass setup just like a dataclass. Hopefully this does not have major backwards compat issues. __allow_unmapped__ can be set on the base class, mixins, etc., it's liberal for now in case people have this problem. * accommodate for ClassVar, these are not considered at all for mapping. Change-Id: Id743aa0456bade9a5d5832796caeecc3dc4accb7
* Improvements on dataclass_transform featureFederico Caselli2022-05-221-3/+44
| | | | Change-Id: Iaf80526b70368cd4ed4147fdce9f6525b113474a
* implement dataclass_transformsMike Bayer2022-05-201-70/+245
| | | | | | | | | | | | | | | | | | | | | | | | Implement a new means of creating a mapped dataclass where instead of applying the `@dataclass` decorator distinctly, the declarative process itself can create the dataclass. MapperProperty and MappedColumn objects themselves take the place of the dataclasses.Field object when constructing the class. The overall approach is made possible at the typing level using pep-681 dataclass transforms [1]. This new approach should be able to completely supersede the previous "dataclasses" approach of embedding metadata into Field() objects, which remains a mutually exclusive declarative setup style (mixing them introduces new issues that are not worth solving). [1] https://peps.python.org/pep-0681/#transform-descriptor-types-example Fixes: #7642 Change-Id: I6ba88a87c5df38270317b4faf085904d91c8a63c
* remove unused "descriptor" param from ColumnPropertyMike Bayer2022-05-171-1/+8
| | | | | | | | | | | this appears to be unused and wasn't documented, even though in the method sig for column_property(). just whack it also repairs a typing issue in decl_base that seemed to somehow not fail previously. Change-Id: Id5c8e716b7e53715778921ab03707642cadbfdee
* Merge "ensure MappedColumn col is mapped under alternate key" into mainmike bayer2022-05-161-7/+14
|\
| * ensure MappedColumn col is mapped under alternate keyMike Bayer2022-05-151-7/+14
| | | | | | | | | | Fixes: #8025 Change-Id: I83ba54f05bd2e5fc87d80f42fbeb6d4d2f2ac5fa
* | revenge of pep 484Mike Bayer2022-05-151-124/+290
|/ | | | | | trying to get remaining must-haves for ORM Change-Id: I66a3ecbbb8e5ba37c818c8a92737b576ecf012f7
* run zimports to match pref changesMike Bayer2022-05-061-1/+0
| | | | | | | I've turned "remove unused imports" back on so this affects some not-used imports in TYPE_CHECKING blocks Change-Id: I8b64ff4ec63f4cee01c2bf41399b691e1c3fb04a
* pep-484: ORM public API, constructorsMike Bayer2022-04-201-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for the moment, abandoning using @overload with relationship() and mapped_column(). The overloads are very difficult to get working at all, and the overloads that were there all wouldn't pass on mypy. various techniques of getting them to "work", meaning having right hand side dictate what's legal on the left, have mixed success and wont give consistent results; additionally, it's legal to have Optional / non-optional independent of nullable in any case for columns. relationship cases are less ambiguous but mypy was not going along with things. we have a comprehensive system of allowing left side annotations to drive the right side, in the absense of explicit settings on the right. so type-centric SQLAlchemy will be left-side driven just like dataclasses, and the various flags and switches on the right side will just not be needed very much. in other matters, one surprise, forgot to remove string support from orm.join(A, B, "somename") or do deprecations for it in 1.4. This is a really not-directly-used structure barely mentioned in the docs for many years, the example shows a relationship being used, not a string, so we will just change it to raise the usual error here. Change-Id: Iefbbb8d34548b538023890ab8b7c9a5d9496ec6e
* read from cls.__dict__ so init_subclass worksMike Bayer2022-04-121-4/+12
| | | | | | | | | | | | | | | | | Modified the :class:`.DeclarativeMeta` metaclass to pass ``cls.__dict__`` into the declarative scanning process to look for attributes, rather than the separate dictionary passed to the type's ``__init__()`` method. This allows user-defined base classes that add attributes within an ``__init_subclass__()`` to work as expected, as ``__init_subclass__()`` can only affect the ``cls.__dict__`` itself and not the other dictionary. This is technically a regression from 1.3 where ``__dict__`` was being used. Additionally makes the reference between ClassManager and the declarative configuration object a weak reference, so that it can be discarded after mappers are set up. Fixes: #7900 Change-Id: I3c2fd4e227cc1891aa4bb3d7d5b43d5686f9f27c
* prevent Mapped[] auto-column logic w/ fixed tableMike Bayer2022-03-021-2/+8
| | | | | | | | | When a class has __table__, people will still want to annotate the attributes on classes, so make sure a Mapped annotation without a right side is only interpreted as a column if there is no __table__ Change-Id: I7da4b4c43c4d2c8b6834b781569cb551e75b57b1
* undefer column name sooner to accommodate compositesMike Bayer2022-02-211-1/+5
| | | | | | | | | This was from adding composite class introspection as a means of determining column name, cols need to have their normal attribute name set up already. Fixes: #7751 Change-Id: I1fe61c135af9b1bf9bc289f683640e63bcc69045
* establish mypy / typing approach for v2.0Mike Bayer2022-02-131-84/+204
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | large patch to get ORM / typing efforts started. this is to support adding new test cases to mypy, support dropping sqlalchemy2-stubs entirely from the test suite, validate major ORM typing reorganization to eliminate the need for the mypy plugin. * New declarative approach which uses annotation introspection, fixes: #7535 * Mapped[] is now at the base of all ORM constructs that find themselves in classes, to support direct typing without plugins * Mypy plugin updated for new typing structures * Mypy test suite broken out into "plugin" tests vs. "plain" tests, and enhanced to better support test structures where we assert that various objects are introspected by the type checker as we expect. as we go forward with typing, we will add new use cases to "plain" where we can assert that types are introspected as we expect. * For typing support, users will be much more exposed to the class names of things. Add these all to "sqlalchemy" import space. * Column(ForeignKey()) no longer needs to be `@declared_attr` if the FK refers to a remote table * composite() attributes mapped to a dataclass no longer need to implement a `__composite_values__()` method * with_variant() accepts multiple dialect names Change-Id: I22797c0be73a8fbbd2d6f5e0c0b7258b17fe145d Fixes: #7535 Fixes: #7551 References: #6810
* initial reorganize for static typingMike Bayer2022-01-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | start applying foundational annotations to key elements. two main elements addressed here: 1. removal of public_factory() and replacement with explicit functions. this just works much better with typing. 2. typing support for column expressions and operators. The biggest part of this involves stubbing out all the ColumnOperators methods under ColumnElement in a TYPE_CHECKING section. Took me a while to see this method vs. much more complicated things I thought I needed. Also for this version implementing #7519, ColumnElement types against the Python type and not TypeEngine. it is hoped this leads to easier transferrence between ORM/Core as well as eventual support for result set typing. Not clear yet how well this approach will work and what new issues it may introduce. given the current approach we now get full, rich typing for scenarios like this: from sqlalchemy import column, Integer, String, Boolean c1 = column('a', String) c2 = column('a', Integer) expr1 = c2.in_([1, 2, 3]) expr2 = c2 / 5 expr3 = -c2 expr4_a = ~(c2 == 5) expr4_b = ~column('q', Boolean) expr5 = c1 + 'x' expr6 = c2 + 10 Fixes: #7519 Fixes: #6810 Change-Id: I078d9f57955549f6f7868314287175f6c61c44cb
View Lorry Controller Status