---
- branch: MAIN
  date: Tue Apr  2 18:11:22 UTC 2024
  files:
  - new: '1.75'
    old: '1.74'
    path: pkgsrc/databases/py-sqlalchemy/Makefile
    pathrev: pkgsrc/databases/py-sqlalchemy/Makefile@1.75
    type: modified
  - new: '1.66'
    old: '1.65'
    path: pkgsrc/databases/py-sqlalchemy/distinfo
    pathrev: pkgsrc/databases/py-sqlalchemy/distinfo@1.66
    type: modified
  id: 20240402T181122Z.4a7415b1b9613aca17cb23fc09918e667ab79cb7
  log: "py-sqlalchemy: updated to 2.0.29\n\n2.0.29\n\nReleased: March 23, 2024\norm\n\n[orm]
    [usecase]\n\nAdded 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.\n\n[orm] [bug]\n\nFixed Declarative issue where typing
    a relationship using Relationship rather than Mapped would inadvertently pull
    in the 窶彭ynamic窶� relationship loader strategy for that attribute.\n\n[orm]
    [bug]\n\nFixed 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.\n\n[orm] [bug] [regression]\n\nFixed 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.\n\nengine\n\n[engine]
    [bug]\n\nFixed issue in 窶廬nsert Many Values窶� Behavior for INSERT statements
    feature where using a primary key column with an 窶彿nline 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.\n\n[engine]
    [bug]\n\nMade 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 窶徭ymmetrical窶�
    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
    窶徭entinel 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 窶å»\x9Aan窶å\x86²
    match sentinel values in result set to parameter sets窶�. Rather than attempt
    to further explain and document this implementation detail of the 窶彿nsertmanyvalues窶�
    feature including a public version of the new method, the approach is intead revised
    to \nno 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 窶徭entinel窶�
    column for bulk INSERT is not receiving and returning the same value type, the
    窶å»\x9Aan窶å\x86² match窶� error will be raised, however the mitigation
    is straightforward in that the same Python datatype should be passed as that returned.\n\nsql\n\n[sql]
    [bug] [regression]\n\nFixed regression from the 1.4 series where the refactor
    of the TypeEngine.with_variant() method introduced at 窶忤ith_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 窶徭chema窶� 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.\n\ntyping\n\n[typing] [bug]\n\nFixed
    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.\n\npostgresql\n\n[postgresql] [usecase]\n\nThe
    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.\n\ntests\n\n[tests]
    [bug]\n\nBackported 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.\n"
  module: pkgsrc
  subject: 'CVS commit: pkgsrc/databases/py-sqlalchemy'
  unixtime: '1712081482'
  user: adam