delta/python-packages/sqlalchemy.git/lib/sqlalchemy/util, branch rel_2_0_6 github.com: zzzeek/sqlalchemy.git update for mypy 1.1.1 2023-03-08T18:52:41+00:00 Mike Bayer mike_mp@zzzcomputing.com 2023-03-08T17:14:01+00:00 bcbb4007bbfa5102d7e53fea8aac50e528d4d1f2 looks like mypy 1.1.1 slipped in after the last jenkins pep484 build for SQLAlchemy. update for its new issues. Change-Id: Ifca967a75d5e592c04b0138aeda9b646067fe59b 
looks like mypy 1.1.1 slipped in after the last jenkins pep484 build
for SQLAlchemy.  update for its new issues.

Change-Id: Ifca967a75d5e592c04b0138aeda9b646067fe59b
KeyFuncDict regression fixes and dataclass fixes 2023-03-05T22:58:39+00:00 Mike Bayer mike_mp@zzzcomputing.com 2023-03-04T20:31:41+00:00 4b5e7e4f5bc262ac5b4cb8f93a594bfa1507b9e6 adapt None-key warning for non-mapped attributes Fixed multiple regressions due to :ticket:`8372`, involving :func:`_orm.attribute_mapped_collection` (now called :func:`_orm.attribute_keyed_dict`). First, the collection was no longer usable with "key" attributes that were not themselves ordinary mapped attributes; attributes linked to descriptors and/or association proxy attributes have been fixed. Second, if an event or other operation needed access to the "key" in order to populate the dictionary from an mapped attribute that was not loaded, this also would raise an error inappropriately, rather than trying to load the attribute as was the behavior in 1.4. This is also fixed. For both cases, the behavior of :ticket:`8372` has been expanded. :ticket:`8372` introduced an error that raises when the derived key that would be used as a mapped dictionary key is effectively unassigned. In this change, a warning only is emitted if the effective value of the ".key" attribute is ``None``, where it cannot be unambiguously determined if this ``None`` was intentional or not. ``None`` will be not supported as mapped collection dictionary keys going forward (as it typically refers to NULL which means "unknown"). Setting :paramref:`_orm.attribute_keyed_dict.ignore_unpopulated_attribute` will now cause such ``None`` keys to be ignored as well. Add value constructors to dictionary collections Added constructor arguments to the built-in mapping collection types including :class:`.KeyFuncDict`, :func:`_orm.attribute_keyed_dict`, :func:`_orm.column_keyed_dict` so that these dictionary types may be constructed in place given the data up front; this provides further compatibility with tools such as Python dataclasses ``.asdict()`` which relies upon invoking these classes directly as ordinary dictionary classes. Fixes: #9418 Fixes: #9424 Change-Id: Ib16c4e690b7ac3fcc34df2f139cad61c6c4b2b19 
adapt None-key warning for non-mapped attributes

Fixed multiple regressions due to :ticket:`8372`, involving
:func:`_orm.attribute_mapped_collection` (now called
:func:`_orm.attribute_keyed_dict`).

First, the collection was no longer usable with "key" attributes that were
not themselves ordinary mapped attributes; attributes linked to descriptors
and/or association proxy attributes have been fixed.

Second, if an event or other operation needed access to the "key" in order
to populate the dictionary from an mapped attribute that was not
loaded, this also would raise an error inappropriately, rather than
trying to load the attribute as was the behavior in 1.4.  This is also
fixed.

For both cases, the behavior of :ticket:`8372` has been expanded.
:ticket:`8372` introduced an error that raises when the derived key that
would be used as a mapped dictionary key is effectively unassigned. In this
change, a warning only is emitted if the effective value of the ".key"
attribute is ``None``, where it cannot be unambiguously determined if this
``None`` was intentional or not. ``None`` will be not supported as mapped
collection dictionary keys going forward (as it typically refers to NULL
which means "unknown"). Setting
:paramref:`_orm.attribute_keyed_dict.ignore_unpopulated_attribute` will now
cause such ``None`` keys to be ignored as well.

Add value constructors to dictionary collections

Added constructor arguments to the built-in mapping collection types
including :class:`.KeyFuncDict`, :func:`_orm.attribute_keyed_dict`,
:func:`_orm.column_keyed_dict` so that these dictionary types may be
constructed in place given the data up front; this provides further
compatibility with tools such as Python dataclasses ``.asdict()`` which
relies upon invoking these classes directly as ordinary dictionary classes.

Fixes: #9418
Fixes: #9424
Change-Id: Ib16c4e690b7ac3fcc34df2f139cad61c6c4b2b19
apply a fixed locals w/ Mapped to all de-stringify 2023-02-27T03:20:11+00:00 Mike Bayer mike_mp@zzzcomputing.com 2023-02-21T15:34:01+00:00 681055f9fb5230d344a67f47b0c60fc1a5804b3e 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 
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
Remove `typing.Self` workaround 2023-02-08T14:23:40+00:00 Yurii Karabas 1998uriyyo@gmail.com 2023-02-07T22:43:26+00:00 7e4c4b8d5c18100b0db58f4d29fac5494fc95b52 Remove ``typing.Self`` workaround, now using :pep:`673` for most methods that return ``Self``. Pull request courtesy Yurii Karabas. Fixes: #9254 Closes: #9255 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9255 Pull-request-sha: 2947df8ada79f5c3afe9c838e65993302199c2f7 Change-Id: Ic32015ad52e95a61f3913d43ea436aa9402804df 
Remove ``typing.Self`` workaround, now using :pep:`673` for most methods
that return ``Self``. Pull request courtesy Yurii Karabas.

Fixes: #9254
Closes: #9255
Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9255
Pull-request-sha: 2947df8ada79f5c3afe9c838e65993302199c2f7

Change-Id: Ic32015ad52e95a61f3913d43ea436aa9402804df
Add support for typing.Literal in Mapped 2023-02-01T03:02:30+00:00 Frederik Aalund fpa@sbtinstruments.com 2023-01-30T16:50:40+00:00 8e890609eb47f5a273e695154cf143af56807921 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 
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
support NewType in type_annotation_map 2023-01-31T19:13:16+00:00 Mike Bayer mike_mp@zzzcomputing.com 2023-01-30T20:12:52+00:00 a21c715b7a89b0619db0d2d5b31617d17b25a27a 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 
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
2.0 prep 2023-01-26T20:56:52+00:00 Mike Bayer mike_mp@zzzcomputing.com 2023-01-26T18:55:34+00:00 54d23b56df50a3fa230759c8fb117957da20a349 still waiting on two more gerrits but this will set things up Change-Id: I966d4c683972c5b965b8db136509062cc8abfe91 
still waiting on two more gerrits but this will set things up

Change-Id: I966d4c683972c5b965b8db136509062cc8abfe91
add context for warnings emitted from configure_mappers(), autoflush() 2023-01-25T03:03:06+00:00 jonathan vanasco jonathan@2xlp.com 2021-11-12T17:45:54+00:00 03212e5aefb3d5c912d25274f447eb9c493f7268 Improved the notification of warnings that are emitted within the configure mappers or flush process, which are often invoked as part of a different operation, to add additional context to the message that indicates one of these operations as the source of the warning within operations that may not be obviously related. Fixes: #7305 Change-Id: I79da7a6a5d4cf67d57615d0ffc2b8d8454011c84 
Improved the notification of warnings that are emitted within the configure
mappers or flush process, which are often invoked as part of a different
operation, to add additional context to the message that indicates one of
these operations as the source of the warning within operations that may
not be obviously related.

Fixes: #7305
Change-Id: I79da7a6a5d4cf67d57615d0ffc2b8d8454011c84
refactor code generation tools , include --check command 2023-01-18T20:07:55+00:00 Mike Bayer mike_mp@zzzcomputing.com 2023-01-18T17:45:42+00:00 cd96ffe287e26651f8dce4f688bf87af1e423f06 in particular it looks like CI was not picking up on the "git diff" oriented commands, which were failing to run due to pathing issues. As we were setting cwd for black/zimports relative to sqlalchemy library, and tox installs it in the venv, black/zimports would fail to run from tox, and since these are subprocess.run we didn't pick up the failure. This overall locks down how zimports/black are run so that we are definitely from the source root, by using the location of tools/ to determine the root. Fixes: #8892 Change-Id: I7c54b747edd5a80e0c699b8456febf66d8b62375 
in particular it looks like CI was not picking up on the
"git diff" oriented commands, which were failing to run due
to pathing issues.  As we were setting cwd for black/zimports
relative to sqlalchemy library, and tox installs it in
the venv, black/zimports would fail to run from tox, and
since these are subprocess.run we didn't pick up the
failure.

This overall locks down how zimports/black are run
so that we are definitely from the source root, by using
the location of tools/ to determine the root.

Fixes: #8892
Change-Id: I7c54b747edd5a80e0c699b8456febf66d8b62375
dont assume copy_with() on builtins list, dict, etc; improve error msg. 2023-01-16T19:23:49+00:00 Mike Bayer mike_mp@zzzcomputing.com 2023-01-16T15:31:39+00:00 046272e06aa3284a87e0dd1f90d2242fb434de10 Fixed issue where using an ``Annotated`` type in the ``type_annotation_map`` which itself contained a plain container type (e.g. ``list``, ``dict``) generic type as the target type would produce an internal error where the ORM were trying to interpret the ``Annotated`` instance. Added an error message when a :func:`_orm.relationship` is mapped against an abstract container type, such as ``Mapped[Sequence[B]]``, without providing the :paramref:`_orm.relationship.container_class` parameter which is necessary when the type is abstract. Previously the the abstract container would attempt to be instantiated and fail. Fixes: #9099 Fixes: #9100 Change-Id: I18aa6abd5451c5ac75a9caed8441ff0cd8f44589 
Fixed issue where using an ``Annotated`` type in the
``type_annotation_map`` which itself contained a plain container type (e.g.
``list``, ``dict``) generic type as the target type would produce an
internal error where the ORM were trying to interpret the ``Annotated``
instance.

Added an error message when a :func:`_orm.relationship` is mapped against
an abstract container type, such as ``Mapped[Sequence[B]]``, without
providing the :paramref:`_orm.relationship.container_class` parameter which
is necessary when the type is abstract. Previously the the abstract
container would attempt to be instantiated and fail.

Fixes: #9099
Fixes: #9100
Change-Id: I18aa6abd5451c5ac75a9caed8441ff0cd8f44589