summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/orm/decl_api.py
Commit message (Collapse)AuthorAgeFilesLines
* Fix usage of `Annotated` in `DeclarativeBase` docstring (#9751)Viicos2023-05-081-1/+1
|
* add deterministic imv returning ordering using sentinel columnsMike Bayer2023-04-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* establish column_property and query_expression as readonly from a dc perspectiveMike Bayer2023-04-121-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixed bug in ORM Declarative Dataclasses where the :func:`_orm.queryable_attribute` and :func:`_orm.column_property` constructs, which are documented as read-only constructs in the context of a Declarative mapping, could not be used with a :class:`_orm.MappedAsDataclass` class without adding ``init=False``, which in the case of :func:`_orm.queryable_attribute` was not possible as no ``init`` parameter was included. These constructs have been modified from a dataclass perspective to be assumed to be "read only", setting ``init=False`` by default and no longer including them in the pep-681 constructor. The dataclass parameters for :func:`_orm.column_property` ``init``, ``default``, ``default_factory``, ``kw_only`` are now deprecated; these fields don't apply to :func:`_orm.column_property` as used in a Declarative dataclasses configuration where the construct would be read-only. Also added read-specific parameter :paramref:`_orm.queryable_attribute.compare` to :func:`_orm.queryable_attribute`; :paramref:`_orm.queryable_attribute.repr` was already present. Added missing :paramref:`_orm.mapped_column.active_history` parameter to :func:`_orm.mapped_column` construct. Fixes: #9628 Change-Id: I2ab44d6b763b20410bd1ebb5ac949a6d223f1ce2
* update for mypy 1.1.1Mike Bayer2023-03-081-10/+10
| | | | | | | looks like mypy 1.1.1 slipped in after the last jenkins pep484 build for SQLAlchemy. update for its new issues. Change-Id: Ifca967a75d5e592c04b0138aeda9b646067fe59b
* add dataclasses callable and apply annotations more strictlyMike Bayer2023-02-161-1/+13
| | | | | | | | | | | | | | | | | 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
* fix typo "Annotation" -> "Annotated" and use typing_extensionsMike Bayer2023-02-141-2/+2
| | | | | Fixes: #9305 Change-Id: I9f0ab24f609f6f557b5780209a85f0abe82b363e
* check for superclasses of user defined initMike Bayer2023-02-061-1/+1
| | | | | | | | | | | | | | | Fixed regression caused by the fix for :ticket:`9171`, which itself was fixing a regression, involving the mechanics of ``__init__()`` on classes that extend from :class:`_orm.DeclarativeBase`. The change made it such that ``__init__()`` was applied to the user-defined base if there were no ``__init__()`` method directly on the class. This has been adjusted so that ``__init__()`` is applied only if no other class in the hierarchy of the user-defined base has an ``__init__()`` method. This again allows user-defined base classes based on :class:`_orm.DeclarativeBase` to include mixins that themselves include a custom ``__init__()`` method. Fixes: #9249 Change-Id: I78f32590ce9ffe245eccb4bd5bd7c884d4e015d5
* Merge "Add support for typing.Literal in Mapped" into mainmike bayer2023-02-011-2/+12
|\
| * Add support for typing.Literal in MappedFrederik Aalund2023-01-311-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Unify doc typing" into mainFederico Caselli2023-01-311-1/+1
|\ \ | |/ |/|
| * Unify doc typingHarry Lees2023-01-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ### Description <!-- Describe your changes in detail --> Fixes #9168 This PR replaces common occurrences of [PEP 585](https://peps.python.org/pep-0585/) style type annotations with annotations compatible with older versions of Python. I searched for instances of the following supported types from the PEP and replaced with their legacy typing couterparts. * tuple # typing.Tuple * list # typing.List * dict # typing.Dict * set # typing.Set * frozenset # typing.FrozenSet * type # typing.Type ``` grep -r "list\[.*\]" ./build --exclude-dir="./build/venv/*" --exclude-dir="./build/output/*" --exclude="changelog_[0-9]*\.rst" ``` I excluded changelog files from being altered, I think some of these could be changed if necessary but others are likely to require manual checking as the change may target the new typing style specifically. For any examples that included imports, I tried to ensure that the correct typing imports were included and properly ordered. ### Checklist <!-- go over following points. check them with an `x` if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once) --> This pull request is: - [x] A documentation / typographical error fix - Good to go, no issue or tests are needed - [ ] 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: #9198 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9198 Pull-request-sha: 05ad4651b57c6275b29433e5e76e166344ba6c4c Change-Id: I41b93b3dee85f9fe00cfbb3d3eb011212795de29
* | support NewType in type_annotation_mapMike Bayer2023-01-311-9/+22
|/ | | | | | | | | | | | | | | | | Added support for :pep:`484` ``NewType`` to be used in the :paramref:`_orm.registry.type_annotation_map` as well as within :class:`.Mapped` constructs. These types will behave in the same way as custom subclasses of types right now; they must appear explicitly within the :paramref:`_orm.registry.type_annotation_map` to be mapped. Within this change, the lookup between decl_api._resolve_type and TypeEngine._resolve_for_python_type is streamlined to not inspect the given type multiple times, instead passing in from decl_api to TypeEngine the already "flattened" version of a Generic or NewType type. Fixes: #9175 Change-Id: I227cf84b4b88e4567fa2d1d7da0c05b54e00c562
* Merge "MappedAsDataclass applies @dataclasses.dataclass unconditionally" ↵mike bayer2023-01-311-2/+12
|\ | | | | | | into main
| * MappedAsDataclass applies @dataclasses.dataclass unconditionallyMike Bayer2023-01-301-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 __init__ to DeclarativeBase directlyMike Bayer2023-01-281-1/+50
|/ | | | | | | | | | | | | | | | Fixed regression in :class:`.DeclarativeBase` class where the registry's default constructor would not be applied to the base itself, which is different from how the previous :func:`_orm.declarative_base` construct works. This would prevent a mapped class with its own ``__init__()`` method from calling ``super().__init__()`` in order to access the registry's default constructor and automatically populate attributes, instead hitting ``object.__init__()`` which would raise a ``TypeError`` on any arguments. This is a very simple change in code, however explaining it is very complicated. Fixes: #9171 Change-Id: I4baecdf671861a8198d835e286fe19a51ecda126
* clarify __table__, local_tableMike Bayer2023-01-201-2/+10
| | | | | | | | These are typed as FromClause, make sure this is stated up front indicating Table as a subset of possible object types. Change-Id: I15961a69d3655600249e3cfe6c4b3372f97d4485 References: #9130
* super-fine pass through the metadata tutorialMike Bayer2023-01-151-2/+122
| | | | | | | | | | try to keep the wordiness down here, using sidebars and topics for non-essential information. Sphinx seems to read out attrs from under TYPE_CHECKING sections now so link out the attrs in DeclarativeBase w/ docstrings, not sure why we didn't think of this earlier. looks great Change-Id: Ib2e07e3606185998561c2d77b2564fd3eddb4d75
* Use field_specifiers instead of deprecated field_descriptorsFederico Caselli2023-01-081-2/+2
| | | | | | | | The Data Class Transforms argument ``field_descriptors`` was renamed to ``field_specifiers`` in the accepted version of PEP 681. Fixes: #9067 Change-Id: Ic13ea93c157325c3b60e65f328a364da68ea1c46
* happy new year 2023Mike Bayer2023-01-031-1/+1
| | | | Change-Id: I625af65b3fb1815b1af17dc2ef47dd697fdc3fb1
* Improve support for enum in mapped classesFederico Caselli2022-11-291-0/+36
| | | | | | | | | | 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
* identify unresolvable Mapped typesMike Bayer2022-11-281-0/+4
| | | | | | | | | | | | | | | | | 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
* try to support mypy 0.990Mike Bayer2022-11-091-2/+2
| | | | | | | | | | | 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
* DeclarativeBase ``__table__`` annotation is not optionalFederico Caselli2022-10-221-1/+1
| | | | Change-Id: I92bfc0cf58fa2e6f9d7e8055f1a337ec806c1410
* Improve typing of DeclarativeBaseFederico Caselli2022-10-191-1/+5
| | | | | | | Also allow mapped columns inside indexes, unique cosntraints, primary key constriant Fixes: #8645 Change-Id: If37ab85ead0fbd1125cd6329c2f01a031777b081
* call super().__init_subclass__(); support GenericAliasMike Bayer2022-10-191-1/+1
| | | | | | | | | | | | | 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
* reorganize Mapped[] super outside of MapperPropertyMike Bayer2022-10-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+10
| | | | | Fixes: #8346 Change-Id: I964629e3bd25221bf6df6ab31c59b3ce1983cd9a
* Ensure that a daclarative base is not used directlyFederico Caselli2022-07-181-10/+24
| | | | | Fixes: #8248 Change-Id: I4f4c690dd8659eaf74e9c757d681e9edc7d33eee
* update ORM declarative docs for new featuresMike Bayer2022-07-161-198/+236
| | | | | | | I screwed up a rebase or something so this was temporarily in Ic51a12de3358f3a451bd7cf3542b375569499fc1 Change-Id: I847ee1336381221c0112b67854df022edf596b25
* make anno-only Mapped[] column available for mixinsMike Bayer2022-07-151-0/+10
| | | | | | | | | | | | | | 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
* Minor cleanupFederico Caselli2022-07-131-1/+2
| | | | | | | - remove unnecessary postgresql visit that's equal to the default compiler - clarify type_annotation_map documentation Change-Id: I0c1fa212d06f6af799a5894802574250622c855e
* some typing fixesMike Bayer2022-06-031-6/+8
| | | | | | | | | | | | | | | | | | | | | | * 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-17/+33
| | | | Change-Id: Iaf80526b70368cd4ed4147fdce9f6525b113474a
* implement dataclass_transformsMike Bayer2022-05-201-2/+140
| | | | | | | | | | | | | | | | | | | | | | | | 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
* revenge of pep 484Mike Bayer2022-05-151-82/+147
| | | | | | trying to get remaining must-haves for ORM Change-Id: I66a3ecbbb8e5ba37c818c8a92737b576ecf012f7
* run zimports to match pref changesMike Bayer2022-05-061-2/+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/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+6
| | | | | | | | | | | | | | | | | 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
* update flake8 noqa skips with proper syntaxFederico Caselli2022-04-111-1/+1
| | | | Change-Id: I42ed77f559e3ee5b8c600d98457ee37803ef0ea6
* pep-484 for sqlalchemy.event; use future annotationsMike Bayer2022-02-151-0/+3
| | | | | | | | | | __future__.annotations mode allows us to use non-string annotations for argument and return types in most cases, but more importantly it removes a large amount of runtime overhead that would be spent in evaluating the annotations. Change-Id: I2f5b6126fe0019713fc50001be3627b664019ede References: #6810
* establish mypy / typing approach for v2.0Mike Bayer2022-02-131-23/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* mypy: sqlalchemy.utilMike Bayer2022-01-241-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting to set up practices and conventions to get the library typed. Key goals for typing are: 1. whole library can pass mypy without any strict turned on. 2. we can incrementally turn on some strict flags on a per-package/ module basis, as here we turn on more strictness for sqlalchemy.util, exc, and log 3. mypy ORM plugin tests work fully without sqlalchemy2-stubs installed 4. public facing methods all have return types, major parameter signatures filled in also 5. Foundational elements like util etc. are typed enough so that we can use them in fully typed internals higher up the stack. Conventions set up here: 1. we can use lots of config in setup.cfg to limit where mypy is throwing errors and how detailed it should be in different packages / modules. We can use this to push up gerrits that will pass tests fully without everything being typed. 2. a new tox target pep484 is added. this links to a new jenkins pep484 job that works across all projects (alembic, dogpile, etc.) We've worked around some mypy bugs that will likely be around for awhile, and also set up some core practices for how to deal with certain things such as public_factory modules (mypy won't accept a module from a callable at all, so need to use simple type checking conditionals). References: #6810 Change-Id: I80be58029896a29fd9f491aa3215422a8b705e12
* detect map_imperatively() called twiceMike Bayer2022-01-181-0/+5
| | | | | | | | | | | | | | | | Fixed issue where calling upon :meth:`_orm.regsitry.map_imperatively` more than once for the same class would produce an unexpected error, rather than an informative error that the target class is already mapped. This behavior differed from that of the :func:`_orm.mapper` function which does report an informative message already. For 2.0, this change also cleans up the logic that detects against `Mapper()` or `_mapper()` being invoked directly. 1.4's backport will take on a different format as `mapper()` is still public API in that release. Fixes: #7579 Change-Id: Ie74a1a2e97f8b6a81ac1942040edd8cae82f4bd8
* Initial ORM typing layoutMike Bayer2022-01-141-18/+166
| | | | | | | | | | | | | | | | | | | | | | | | | | introduces: 1. new mapped_column() helper 2. DeclarativeBase helper 3. declared_attr has been re-typed 4. rework of Mapped[] to return InstrumentedAtribute for class get, so works without Mapped itself having expression methods 5. ORM constructs now generic on [_T] also includes some early typing work, most of which will be in later commits: 1. URL and History become typing.NamedTuple 2. come up with type-checking friendly way of type checking cy extensions, where type checking will be applied to the py versions, just needed to come up with a succinct conditional pattern for the imports References: #6810 References: #7535 References: #7562 Change-Id: Ie5d9a44631626c021d130ca4ce395aba623c71fb
* 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
* remove internal use of metaclassesMike Bayer2022-01-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All but one metaclass used internally can now be replaced using __init_subclass__(). Within this patch we remove: * events._EventMeta * sql.visitors.TraversibleType * sql.visitors.InternalTraversibleType * testing.fixtures.FindFixture * testing.fixtures.FindFixtureDeclarative * langhelpers.EnsureKWArgType * sql.functions._GenericMeta * sql.type_api.VisitableCheckKWArg (was a mixture of TraversibleType and EnsureKWArgType) The remaining internal class is MetaOptions used by the sql.Options object which is in turn currently mostly for ORM internal use, as this type implements class level overrides for the ``+`` operator. For declarative, removing DeclarativeMeta in place of an `__init_subclass__()` class would not be fully feasible as it would break backwards compatibility with applications that refer to this class explicitly, but also DeclarativeMeta intercepts class-level attribute set and delete operations which is a widely used pattern. An option for declarative base to use `__init_subclass__()` should be provided but this is out of scope for this particular change. Change-Id: I8aa898c7ab59d887739037d34b1cbab36521ab78 References: #6810
* happy new year 2022Mike Bayer2022-01-061-1/+1
| | | | Change-Id: I49abf2607e0eb0623650efdf0091b1fb3db737ea
* Remove all remaining removed_in_20 warnings slated for removalMike Bayer2022-01-051-13/+10
| | | | | | | | | | | | | | | | | | | | | | | | | Finalize all remaining removed-in-2.0 changes so that we can begin doing pep-484 typing without old things getting in the way (we will also have to do public_factory). note there are a few "moved_in_20()" and "became_legacy_in_20()" warnings still in place. The SQLALCHEMY_WARN_20 variable is now removed. Also removed here are the legacy "in place mutators" for Select statements, and some keyword-only argument signatures in Core have been added. Also in the big change department, the ORM mapper() function is removed entirely; the Mapper class is otherwise unchanged, just the public-facing API function. Mappers are now always given a registry in which to participate, however the argument signature of Mapper is not changed. ideally "registry" would be the first positional argument. Fixes: #7257 Change-Id: Ic70c57b9f1cf7eb996338af5183b11bdeb3e1623
* Fix missing class attributes when using __class_getitem__Kai Mueller2021-12-221-1/+7
| | | | | | | | | | | | | | | | Fixed issue where the ``__class_getitem__()`` method of the generated declarative base class by :func:`_orm.as_declarative` would lead to inaccessible class attributes such as ``__table__``, for cases where a ``Generic[T]`` style typing declaration were used in the class hierarchy. This is in continuation from the basic addition of ``__class_getitem__()`` in :ticket:`7368`. Pull request courtesy Kai Mueller. Fixes: #7462 Closes: #7470 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7470 Pull-request-sha: d5e5765e0e5542149f116ed9ccff1b3e2e32dee5 Change-Id: I6418af6d34532ff181343884bd419d9c2684e617
* Merge "Removals: MetaData.bind, Table.bind, all other .bind" into mainmike bayer2021-12-031-30/+2
|\
View Lorry Controller Status