Log message:
py-sqlalchemy: updated to 2.0.29

2.0.29

Released: March 23, 2024
orm

[orm] [usecase]

Added support for the PEP 695 TypeAliasType construct as well as the python 3.12 \ 
native type keyword to work with ORM Annotated Declarative form when using these \ 
constructs to link to a PEP 593 Annotated container, allowing the resolution of \ 
the Annotated to proceed when these constructs are used in a Mapped typing \ 
container.

[orm] [bug]

Fixed Declarative issue where typing a relationship using Relationship rather \ 
than Mapped would inadvertently pull in the “dynamic” relationship loader \ 
strategy for that attribute.

[orm] [bug]

Fixed issue in ORM annotated declarative where using mapped_column() with an \ 
mapped_column.index or mapped_column.unique setting of False would be overridden \ 
by an incoming Annotated element that featured that parameter set to True, even \ 
though the immediate mapped_column() element is more specific and should take \ 
precedence. The logic to reconcile the booleans has been enhanced to accommodate \ 
a local value of False as still taking precedence over an incoming True value \ 
from the annotated element.

[orm] [bug] [regression]

Fixed regression from version 2.0.28 caused by the fix for 11085 where the newer \ 
method of adjusting post-cache bound parameter values would interefere with the \ 
implementation for the subqueryload() loader option, which has some more legacy \ 
patterns in use internally, when the additional loader criteria feature were \ 
used with this loader option.

engine

[engine] [bug]

Fixed issue in “Insert Many Values” Behavior for INSERT statements feature \ 
where using a primary key column with an “inline execute” default generator \ 
such as an explicit Sequence with an explcit schema name, while at the same time \ 
using the Connection.execution_options.schema_translate_map feature would fail \ 
to render the sequence or the parameters properly, leading to errors.

[engine] [bug]

Made a change to the adjustment made in version 2.0.10 for 9618, which added the \ 
behavior of reconciling RETURNING rows from a bulk INSERT to the parameters that \ 
were passed to it. This behavior included a comparison of already-DB-converted \ 
bound parameter values against returned row values that was not always \ 
“symmetrical” for SQL column types such as UUIDs, depending on specifics of \ 
how different DBAPIs receive such values versus how they return them, \ 
necessitating the need for additional “sentinel value resolver” methods on \ 
these column types. Unfortunately this broke third party column types such as \ 
UUID/GUID types in libraries like SQLModel which did not implement this special \ 
method, raising an error “Can’t match sentinel values in result set to \ 
parameter sets”. Rather than attempt to further explain and document this \ 
implementation detail of the “insertmanyvalues” feature including a public \ 
version of the new method, the approach is intead revised to 
no longer need this extra conversion step, and the logic that does the \ 
comparison now works on the pre-converted bound parameter value compared to the \ 
post-result-processed value, which should always be of a matching datatype. In \ 
the unusual case that a custom SQL column type that also happens to be used in a \ 
“sentinel” column for bulk INSERT is not receiving and returning the same \ 
value type, the “Can’t match” error will be raised, however the mitigation \ 
is straightforward in that the same Python datatype should be passed as that \ 
returned.

sql

[sql] [bug] [regression]

Fixed regression from the 1.4 series where the refactor of the \ 
TypeEngine.with_variant() method introduced at “with_variant()” clones the \ 
original TypeEngine rather than changing the type failed to accommodate for the \ 
.copy() method, which will lose the variant mappings that are set up. This \ 
becomes an issue for the very specific case of a “schema” type, which \ 
includes types such as Enum and ARRAY, when they are then used in the context of \ 
an ORM Declarative mapping with mixins where copying of types comes into play. \ 
The variant mapping is now copied as well.

typing

[typing] [bug]

Fixed typing issue allowing asyncio run_sync() methods to correctly type the \ 
parameters according to the callable that was passed, making use of PEP 612 \ 
ParamSpec variables. Pull request courtesy Francisco R. Del Roio.

postgresql

[postgresql] [usecase]

The PostgreSQL dialect now returns DOMAIN instances when reflecting a column \ 
that has a domain as type. Previously, the domain data type was returned \ 
instead. As part of this change, the domain reflection was improved to also \ 
return the collation of the text types. Pull request courtesy of Thomas \ 
Stephenson.

tests

[tests] [bug]

Backported to SQLAlchemy 2.0 an improvement to the test suite with regards to \ 
how asyncio related tests are run, now using the newer Python 3.11 \ 
asyncio.Runner or a backported equivalent, rather than relying on the previous \ 
implementation based on asyncio.get_running_loop(). This should hopefully \ 
prevent issues with large suite runs on CPU loaded hardware where the event loop \ 
seems to become corrupted, leading to cascading failures.

Log message:
py-sqlalchemy: requires py-cython; fix PLIST; bump revision

Log message:
py-sqlalchemy: update to 2.0.28.

This is a major new version, lots of code cleanups and
adaptations to work better with Python 3.

Log message:
Remove dependencies for Python 3.7

Log message:
py-sqlalchemy: add missing dependency

Bump PKGREVISION.

Log message:
py-sqlalchemy: update to 1.4.48

Version 1.4 is taking on a different focus than other SQLAlchemy releases
in that it is in many ways attempting to serve as a potential migration
point for a more dramatic series of API changes currently planned for release
2.0 of SQLAlchemy. The focus of SQLAlchemy 2.0 is a modernized and slimmed
down API that removes lots of usage patterns that have long been discouraged,
as well as mainstreams the best ideas in SQLAlchemy as first class API features,
with the goal being that there is much less ambiguity in how the API is to be
used, as well as that a series of implicit behaviors and rarely-used API flags
that complicate the internals and hinder performance will be removed.

Log message:
*: bump PKGREVISION for egg.mk users

They now have a tool dependency on py-setuptools instead of a DEPENDS

Log message:
databases: Replace RMD160 checksums with BLAKE2s checksums

All checksums have been double-checked against existing RMD160 and
SHA512 hashes

The following distfiles could not be fetched (some may be only fetched
conditionally):

./databases/cstore/distinfo D6.data.ros.gz
./databases/cstore/distinfo cstore0.2.tar.gz
./databases/cstore/distinfo data4.tar.gz

Log message:
databases: Remove SHA1 distfile hashes

Log message:
py-sqlalchemy: updated to 1.3.22

1.3.22

oracle

[oracle] [bug]

Fixed regression which occured due to 5755 which implemented isolation level \ 
support for Oracle. It has been reported that many Oracle accounts don’t \ 
actually have permission to query the v$transaction view so this feature has \ 
been altered to gracefully fallback when it fails upon database connect, where \ 
the dialect will assume “READ COMMITTED” is the default isolation level as \ 
was the case prior to SQLAlchemy 1.3.21. However, explicit use of the \ 
Connection.get_isolation_level() method must now necessarily raise an exception, \ 
as Oracle databases with this restriction explicitly disallow the user from \ 
reading the current isolation level.