Revisions of python-SQLAlchemy
- update to 2.0.28: * https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.28
- update to 2.0.25: * preliminary support for Python 3.12 pep-695 type alias structures * see https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.25
- update to 2.0.24: * https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.24
- update to 2.0.23: * https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.23 * https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.22 - use generic Cython >= 3 buildrequires https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.19 * see update/delete statements. producing the wrong ON clause for the joinedload. is common when using ORM Declarative mixins. References: #9773 * https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.13 see https://docs.sqlalchemy.org/en/20/changelog/changelog_14.html#change-1.4.46 see https://docs.sqlalchemy.org/en/20/changelog/changelog_14.html#change-1.4.45 Bugfixes, see * https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-1.4.28 * see https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-1.4.27 constraints as well table /view detection. Oracle, PostgreSQL, and MySQL. * bugfixes for various engines, see stringify correctly. Pull request courtesy Andrzej Bartosiński. the path registry is compared to a path registry in all cases; invalid configuration, would fail to raise if the - add upstream fix_test_reflection.patch to fix tests with new sqlite + [orm] [bug] Fixed regression in 1.2.7 caused by #4228, which callable passed to a Session was assumed to be a subclass of Query with class method availability, as opposed to an arbitrary callable. In particular, the dogpile caching example illustrates query_cls as a function and not a Query subclass. + [orm] [bug] Fixed a long-standing regression that occurred in version 1.0, which prevented the use of a custom MapperOption
- Update to 1.4.12 (bsc#1184038): * obsoletes sqlalchemy-7293b3dc0e9eb3dae84ffd831494b85355df8e73.patch in older dists
- use generic Cython >= 3 buildrequires
- update to 2.0.19: * Various bugfixes, see https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.19
- update to 2.0.16: * Python 3.12 support * Fixed regression in the 2.0 series where the default value of validates.include_backrefs got changed to False for the validates() function * Unified the custom PostgreSQL operator definitions * Added support for PostgreSQL 10 NULLS NOT DISTINCT feature of unique indexes and unique constraints * Use proper precedence on PostgreSQL specific operators, such as @> * see https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.16
- Switch documentation to be within the main package. - Update to 2.0.15 # orm * As more projects are using new-style “2.0” ORM querying, it’s becoming apparent that the conditional nature of “autoflush”, being based on whether or not the given statement refers to ORM entities, is becoming more of a key behavior. Up until now, the “ORM” flag for a statement has been loosely based around whether or not the statement returns rows that correspond to ORM entities or columns; the original purpose of the “ORM” flag was to enable ORM-entity fetching rules which apply post-processing to Core result sets as well as ORM loader strategies to the statement. For statements that don’t build on rows that contain ORM entities, the “ORM” flag was considered to be mostly unnecessary. * It still may be the case that “autoflush” would be better taking effect for all usage of Session.execute() and related methods, even for purely Core SQL constructs. However, this still could impact legacy cases where this is not expected and may be more of a 2.1 thing. For now however, the rules for the “ORM-flag” have been opened up so that a statement that includes ORM entities or attributes anywhere within, including in the WHERE / ORDER BY / GROUP BY clause alone, within scalar subqueries, etc. will enable this flag. This will cause “autoflush” to occur for such statements and also be visible via the ORMExecuteState.is_orm_statement event-level attribute. References: #9805 # postgresql * Repaired the base Uuid datatype for the PostgreSQL dialect to
- drop unnecessary mypy dependency
- update to SQLalchemy 2.0.x: * 1.x remains available as SQLAlchemy1 Long list of changes, see https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.12 https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.11 https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.10 https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.9 https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.8 https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.7 https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.6 https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.5 https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.4 https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.3 https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.2 https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.1
- update to 1.4.46: * A new deprecation “uber warning” is now emitted at runtime the first time any SQLAlchemy 2.0 deprecation warning would normally be emitted, but the SQLALCHEMY_WARN_20 environment variable is not set. see https://docs.sqlalchemy.org/en/20/changelog/changelog_14.html#change-1.4.46
Automatic submission by obs-autosubmit
- update to version 1.4.42: * orm + The Session.execute.bind_arguments dictionary is no longer mutated when passed to Session.execute() and similar; instead, it’s copied to an internal dictionary for state changes. Among other things, this fixes and issue where the “clause” passed to the Session.get_bind() method would be incorrectly referring to the Select construct used for the “fetch” synchronization strategy, when the actual query being emitted was a Delete or Update. This would interfere with recipes for “routing sessions”. References: #8614 + A warning is emitted in ORM configurations when an explicit remote() annotation is applied to columns that are local to the immediate mapped class, when the referenced class does not include any of the same table columns. Ideally this would raise an error at some point as it’s not correct from a mapping point of view. References: #7094 + A warning is emitted when attempting to configure a mapped class within an inheritance hierarchy where the mapper is not given any polymorphic identity, however there is a polymorphic discriminator column assigned. Such classes should be abstract if they never intend to load directly. References: #7545 + Fixed regression for 1.4 in contains_eager() where the “wrap in subquery” logic of joinedload() would be inadvertently triggered for use of the contains_eager() function with similar statements (e.g. those that use distinct(), limit() or offset()), which would then lead to secondary issues with queries that used some combinations of SQL label names and aliasing. This “wrapping” is not appropriate for contains_eager() which has always had the contract that the user-defined SQL statement is unmodified with
- update to 1.4.41: * Fixed issue where use of the :func:`_sql.table` construct, passing a string for the :paramref:`_sql.table.schema` parameter, would fail to take the "schema" string into account when producing a cache key, thus leading to caching collisions if multiple, same-named :func:`_sql.table` constructs with different schemas were used. * Fixed event listening issue where event listeners added to a superclass would be lost if a subclass were created which then had its own listeners associated. The practical example is that of the :class:`.sessionmaker` class created after events have been associated with the :class:`_orm.Session` class. * Hardened the cache key strategy for the :func:`_orm.aliased` and :func:`_orm.with_polymorphic` constructs. While no issue involving actual statements being cached can easily be demonstrated (if at all), these two constructs were not including enough of what makes them unique in their cache keys for caching on the aliased construct alone to be accurate. * Fixed regression appearing in the 1.4 series where a joined-inheritance query placed as a subquery within an enclosing query for that same entity would fail to render the JOIN correctly for the inner query. The issue manifested in two different ways prior and subsequent to version 1.4.18 (related issue :ticket:`6595`), in one case rendering JOIN twice, in the other losing the JOIN entirely. To resolve, the conditions under which "polymorphic loading" are applied have been scaled back to not be invoked for simple joined inheritance queries. * Fixed issue in :mod:`sqlalchemy.ext.mutable` extension where collection links to the parent object would be lost if the object were merged with :meth:`.Session.merge` while also passing :paramref:`.Session.merge.load` as False. * Fixed issue involving :func:`_orm.with_loader_criteria` where a closure variable used as bound parameter value within the lambda would not carry
Displaying revisions 1 - 20 of 117