5248 lines
272 KiB
Plaintext
5248 lines
272 KiB
Plaintext
-------------------------------------------------------------------
|
||
Mon Aug 19 07:10:55 UTC 2024 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to 2.0.32:
|
||
* https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.32
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Jun 19 06:49:52 UTC 2024 - Adrian Schröter <adrian@suse.de>
|
||
|
||
- update to 2.0.31
|
||
* https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.31
|
||
- Python 3.13 support
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Mar 7 08:30:24 UTC 2024 - Adrian Schröter <adrian@suse.de>
|
||
|
||
- update to 2.0.28:
|
||
* https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.28
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Jan 21 10:30:30 UTC 2024 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- 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
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Dec 29 09:04:13 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to 2.0.24:
|
||
* https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.24
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Nov 27 09:11:36 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- 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
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Sep 29 15:23:49 UTC 2023 - Martin Schreiner <martin.schreiner@suse.com>
|
||
|
||
- Update to 2.0.21:
|
||
* Changes from 2.0.21:
|
||
https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.21
|
||
* Changes from 2.0.20:
|
||
https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.20
|
||
- Remove .gitignore files from source tree, removes all rpmlint
|
||
warnings.
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Aug 13 21:41:29 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- use generic Cython >= 3 buildrequires
|
||
|
||
-------------------------------------------------------------------
|
||
Tue Jul 25 18:42:01 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to 2.0.19:
|
||
* Various bugfixes, see
|
||
https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.19
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Jun 19 20:22:29 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- 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
|
||
|
||
-------------------------------------------------------------------
|
||
Tue May 30 15:57:30 UTC 2023 - Daniel Garcia <daniel.garcia@suse.com>
|
||
|
||
- Switch documentation to be within the main package.
|
||
|
||
-------------------------------------------------------------------
|
||
Sat May 20 10:32:50 UTC 2023 - Ben Greiner <code@bnavigator.de>
|
||
|
||
- 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
|
||
make full use of the PG-specific UUID dialect-specific datatype
|
||
when “native_uuid” is selected, so that PG driver behaviors are
|
||
included. This issue became apparent due to the
|
||
insertmanyvalues improvement made as part of #9618, where in a
|
||
similar manner as that of #9739, the asyncpg driver is very
|
||
sensitive to datatype casts being present or not, and the
|
||
PostgreSQL driver-specific native UUID datatype must be invoked
|
||
when this generic type is used so that these casts take place.
|
||
References: #9808
|
||
- Release 2.0.13
|
||
# orm
|
||
* Modified the JoinedLoader implementation to use a simpler
|
||
approach in one particular area where it previously used a
|
||
cached structure that would be shared among threads. The
|
||
rationale is to avoid a potential race condition which is
|
||
suspected of being the cause of a particular crash that’s been
|
||
reported multiple times. The cached structure in question is
|
||
still ultimately “cached” via the compiled SQL cache, so a
|
||
performance degradation is not anticipated.
|
||
References: #9777
|
||
* Fixed regression where use of update() or delete() within a CTE
|
||
construct, then used in a select(), would raise a CompileError
|
||
as a result of ORM related rules for performing ORM-level
|
||
update/delete statements.
|
||
References: #9767
|
||
* Fixed issue in new ORM Annotated Declarative where using a
|
||
ForeignKey (or other column-level constraint) inside of
|
||
mapped_column() which is then copied out to models via pep-593
|
||
Annotated would apply duplicates of each constraint to the
|
||
Column as produced in the target Table, leading to incorrect
|
||
CREATE TABLE DDL as well as migration directives under Alembic.
|
||
References: #9766
|
||
* Fixed issue where using additional relationship criteria with
|
||
the joinedload() loader option, where the additional criteria
|
||
itself contained correlated subqueries that referred to the
|
||
joined entities and therefore also required “adaption” to
|
||
aliased entities, would be excluded from this adaption,
|
||
producing the wrong ON clause for the joinedload.
|
||
References: #9779
|
||
# sql
|
||
* Generalized the MSSQL try_cast() function into the sqlalchemy.
|
||
import namespace so that it may be implemented by third party
|
||
dialects as well. Within SQLAlchemy, the try_cast() function
|
||
remains a SQL Server-only construct that will raise
|
||
CompileError if used with backends that don’t support it.
|
||
* try_cast() implements a CAST where un-castable conversions are
|
||
returned as NULL, instead of raising an error. Theoretically,
|
||
the construct could be implemented by third party dialects for
|
||
Google BigQuery, DuckDB, and Snowflake, and possibly others.
|
||
Pull request courtesy Nick Crews.
|
||
References: #9752
|
||
* Fixed issue in values() construct where an internal compilation
|
||
error would occur if the construct were used inside of a scalar
|
||
subquery.
|
||
References: #9772
|
||
# postgresql
|
||
* Fixed apparently very old issue where the ENUM.create_type
|
||
parameter, when set to its non-default of False, would not be
|
||
propagated when the Column which it’s a part of were copied, as
|
||
is common when using ORM Declarative mixins. References: #9773
|
||
# tests
|
||
* Fixed test that relied on the sys.getsizeof() function to not
|
||
run on pypy, where this function appears to have different
|
||
behavior than it does on cpython. References: #9789
|
||
- PEP517
|
||
- Add missing runtime requirement
|
||
|
||
-------------------------------------------------------------------
|
||
Sun May 14 16:30:22 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to 2.0.13:
|
||
* https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2.0.13
|
||
|
||
-------------------------------------------------------------------
|
||
Fri May 12 13:50:11 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- drop unnecessary mypy dependency
|
||
|
||
-------------------------------------------------------------------
|
||
Thu May 4 15:48:19 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- 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
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Apr 21 12:21:17 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- add sle15_python_module_pythons (jsc#PED-68)
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Apr 13 22:45:14 UTC 2023 - Matej Cepl <mcepl@suse.com>
|
||
|
||
- Make calling of %{sle15modernpython} optional.
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Feb 15 12:34:21 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- 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
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Jan 2 19:33:29 UTC 2023 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to 1.4.45:
|
||
see https://docs.sqlalchemy.org/en/20/changelog/changelog_14.html#change-1.4.45
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Oct 22 16:19:42 UTC 2022 - Arun Persaud <arun@gmx.de>
|
||
|
||
- 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
|
||
the exception of adding the appropriate columns to be fetched.
|
||
References: #8569
|
||
+ Fixed regression where using ORM update() with
|
||
synchronize_session=’fetch’ would fail due to the use of
|
||
evaluators that are now used to determine the in-Python value
|
||
for expressions in the the SET clause when refreshing objects;
|
||
if the evaluators make use of math operators against non-numeric
|
||
values such as PostgreSQL JSONB, the non-evaluable condition
|
||
would fail to be detected correctly. The evaluator now limits
|
||
the use of math mutation operators to numeric types only, with
|
||
the exception of “+” that continues to work for strings as
|
||
well. SQLAlchemy 2.0 may alter this further by fetching the SET
|
||
values completely rather than using evaluation. References:
|
||
#8507
|
||
* engine
|
||
+ Fixed issue where mixing “*” with additional explicitly-named
|
||
column expressions within the columns clause of a select()
|
||
construct would cause result-column targeting to sometimes
|
||
consider the label name or other non-repeated names to be an
|
||
ambiguous target. References: #8536
|
||
* asyncio
|
||
+ Improved implementation of asyncio.shield() used in context
|
||
managers as added in #8145, such that the “close” operation is
|
||
enclosed within an asyncio.Task which is then strongly
|
||
referenced as the operation proceeds. This is per Python
|
||
documentation indicating that the task is otherwise not strongly
|
||
referenced. References: #8516
|
||
* postgresql
|
||
+ aggregate_order_by now supports cache generation. References:
|
||
#8574
|
||
* mysql
|
||
+ Adjusted the regular expression used to match “CREATE VIEW” when
|
||
testing for views to work more flexibly, no longer requiring the
|
||
special keyword “ALGORITHM” in the middle, which was intended to
|
||
be optional but was not working correctly. The change allows
|
||
view reflection to work more completely on MySQL-compatible
|
||
variants such as StarRocks. Pull request courtesy John Bodley.
|
||
References: #8588
|
||
* mssql
|
||
+ Fixed yet another regression in SQL Server isolation level fetch
|
||
(see #8231, #8475), this time with “Microsoft Dynamics CRM
|
||
Database via Azure Active Directory”, which apparently lacks the
|
||
system_views view entirely. Error catching has been extended
|
||
that under no circumstances will this method ever fail, provided
|
||
database connectivity is present. References: #8525
|
||
- Also remove the conditional definition of python_module.
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Sep 17 07:23:58 UTC 2022 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- 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
|
||
forward correctly into additional relationship loaders such as
|
||
:func:`_orm.selectinload` and :func:`_orm.lazyload` after the statement
|
||
were cached, using the stale originally-cached value instead.
|
||
* Fixed regression caused by the fix for :ticket:`8231` released in 1.4.40
|
||
where connection would fail if the user did not have permission to query
|
||
the ``dm_exec_sessions`` or ``dm_pdw_nodes_exec_sessions`` system views
|
||
when trying to determine the current transaction isolation level.
|
||
* Integrated support for asyncpg's ``terminate()`` method call for cases
|
||
where the connection pool is recycling a possibly timed-out connection,
|
||
where a connection is being garbage collected that wasn't gracefully
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Aug 17 03:06:32 UTC 2022 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.4.40:
|
||
* orm
|
||
+ [orm] [bug] Fixed issue where referencing a CTE multiple times
|
||
in conjunction with a polymorphic SELECT could result in
|
||
multiple “clones” of the same CTE being constructed, which would
|
||
then trigger these two CTEs as duplicates. To resolve, the two
|
||
CTEs are deep-compared when this occurs to ensure that they are
|
||
equivalent, then are treated as equivalent. References: #8357
|
||
+ [orm] [bug] A select() construct that is passed a sole ‘*’
|
||
argument for SELECT *, either via string, text(), or
|
||
literal_column(), will be interpreted as a Core-level SQL
|
||
statement rather than as an ORM level statement. This is so that
|
||
the *, when expanded to match any number of columns, will result
|
||
in all columns returned in the result. the ORM- level
|
||
interpretation of select() needs to know the names and types of
|
||
all ORM columns up front which can’t be achieved when '*' is
|
||
used. If '* is used amongst other expressions simultaneously
|
||
with an ORM statement, an error is raised as this can’t be
|
||
interpreted correctly by the ORM. References: #8235
|
||
* orm declarative
|
||
+ [orm] [declarative] [bug] Fixed issue where a hierarchy of
|
||
classes set up as an abstract or mixin declarative classes could
|
||
not declare standalone columns on a superclass that would then
|
||
be copied correctly to a declared_attr callable that wanted to
|
||
make use of them on a descendant class. References: #8190
|
||
* engine
|
||
+ [engine] [usecase] Implemented new
|
||
Connection.execution_options.yield_per execution option for
|
||
Connection in Core, to mirror that of the same yield_per option
|
||
available in the ORM. The option sets both the
|
||
Connection.execution_options.stream_results option at the same
|
||
time as invoking Result.yield_per(), to provide the most common
|
||
streaming result configuration which also mirrors that of the
|
||
ORM use case in its usage pattern. See also: Using Server Side
|
||
Cursors (a.k.a. stream results) - revised documentation
|
||
+ [engine] [bug] Fixed bug in Result where the usage of a buffered
|
||
result strategy would not be used if the dialect in use did not
|
||
support an explicit “server side cursor” setting, when using
|
||
Connection.execution_options.stream_results. This is in error as
|
||
DBAPIs such as that of SQLite and Oracle already use a
|
||
non-buffered result fetching scheme, which still benefits from
|
||
usage of partial result fetching. The “buffered” strategy is now
|
||
used in all cases where
|
||
Connection.execution_options.stream_results is set.
|
||
+ [engine] [bug] Added FilterResult.yield_per() so that result
|
||
implementations such as MappingResult, ScalarResult and
|
||
AsyncResult have access to this method. References: #8199
|
||
* sql
|
||
+ [sql] [bug] Adjusted the SQL compilation for string containment
|
||
functions .contains(), .startswith(), .endswith() to force the
|
||
use of the string concatenation operator, rather than relying
|
||
upon the overload of the addition operator, so that non-standard
|
||
use of these operators with for example bytestrings still
|
||
produces string concatenation operators. References: #8253
|
||
* mypy
|
||
+ [mypy] [bug] Fixed a crash of the mypy plugin when using a
|
||
lambda as a Column default. Pull request curtesy of tchapi.
|
||
References: #8196
|
||
* asyncio
|
||
+ [asyncio] [bug] Added asyncio.shield() to the connection and
|
||
session release process specifically within the __aexit__()
|
||
context manager exit, when using AsyncConnection or AsyncSession
|
||
as a context manager that releases the object when the context
|
||
manager is complete. This appears to help with task cancellation
|
||
when using alternate concurrency libraries such as anyio, uvloop
|
||
that otherwise don’t provide an async context for the connection
|
||
pool to release the connection properly during task
|
||
cancellation. References: #8145
|
||
* postgresql
|
||
+ [postgresql] [bug] Fixed issue in psycopg2 dialect where the
|
||
“multiple hosts” feature implemented for #4392, where multiple
|
||
host:port pairs could be passed in the query string as
|
||
?host=host1:port1&host=host2:port2&host=host3:port3 was not
|
||
implemented correctly, as it did not propagate the “port”
|
||
parameter appropriately. Connections that didn’t use a different
|
||
“port” likely worked without issue, and connections that had
|
||
“port” for some of the entries may have incorrectly passed on
|
||
that hostname. The format is now corrected to pass hosts/ports
|
||
appropriately. As part of this change, maintained support for
|
||
another multihost style that worked unintentionally, which is
|
||
comma-separated ?host=h1,h2,h3&port=p1,p2,p3. This format is
|
||
more consistent with libpq’s query-string format, whereas the
|
||
previous format is inspired by a different aspect of libpq’s URI
|
||
format but is not quite the same thing. If the two styles are
|
||
mixed together, an error is raised as this is ambiguous.
|
||
References: #4392
|
||
* mssql
|
||
+ [mssql] [bug] Fixed issues that prevented the new usage patterns
|
||
for using DML with ORM objects presented at Using INSERT, UPDATE
|
||
and ON CONFLICT (i.e. upsert) to return ORM Objects from working
|
||
correctly with the SQL Server pyodbc dialect. References: #8210
|
||
+ [mssql] [bug] Fixed issue where the SQL Server dialect’s query
|
||
for the current isolation level would fail on Azure Synapse
|
||
Analytics, due to the way in which this database handles
|
||
transaction rollbacks after an error has occurred. The initial
|
||
query has been modified to no longer rely upon catching an error
|
||
when attempting to detect the appropriate system
|
||
view. Additionally, to better support this database’s very
|
||
specific “rollback” behavior, implemented new parameter
|
||
ignore_no_transaction_on_rollback indicating that a rollback
|
||
should ignore Azure Synapse error ‘No corresponding transaction
|
||
found. (111214)’, which is raised if no transaction is present
|
||
in conflict with the Python DBAPI. Initial patch and valuable
|
||
debugging assistance courtesy of @ww2406. See also: Avoiding
|
||
transaction-related exceptions on Azure Synapse Analytics
|
||
References: #8231
|
||
* misc
|
||
+ [bug] [types] Fixed issue where TypeDecorator would not
|
||
correctly proxy the __getitem__() operator when decorating the
|
||
ARRAY datatype, without explicit workarounds. References: #7249
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Jul 9 14:12:13 UTC 2022 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.4.39:
|
||
* orm
|
||
+ [orm] [bug] [regression] Fixed regression caused by #8133 where
|
||
the pickle format for mutable attributes was changed, without a
|
||
fallback to recognize the old format, causing in-place upgrades
|
||
of SQLAlchemy to no longer be able to read pickled data from
|
||
previous versions. A check plus a fallback for the old format is
|
||
now in place. References: #8133
|
||
|
||
- changes from version 1.4.38:
|
||
* orm
|
||
+ [orm] [bug] [regression] Fixed regression caused by #8064 where
|
||
a particular check for column correspondence was made too
|
||
liberal, resulting in incorrect rendering for some ORM
|
||
subqueries such as those using PropComparator.has() or
|
||
PropComparator.any() in conjunction with joined-inheritance
|
||
queries that also use legacy aliasing features. References:
|
||
#8162
|
||
+ [orm] [bug] [sql] Fixed an issue where GenerativeSelect.fetch()
|
||
would not be applied when executing a statement using the ORM.
|
||
References: #8091
|
||
+ [orm] [bug] Fixed issue where a with_loader_criteria() option
|
||
could not be pickled, as is necessary when it is carried along
|
||
for propagation to lazy loaders in conjunction with a caching
|
||
scheme. Currently, the only form that is supported as picklable
|
||
is to pass the “where criteria” as a fixed module-level callable
|
||
function that produces a SQL expression. An ad-hoc “lambda”
|
||
can’t be pickled, and a SQL expression object is usually not
|
||
fully picklable directly. References: #8109
|
||
* engine
|
||
+ [engine] [bug] Repaired a deprecation warning class decorator
|
||
that was preventing key objects such as Connection from having a
|
||
proper __weakref__ attribute, causing operations like Python
|
||
standard library inspect.getmembers() to fail. References:
|
||
#8115
|
||
* sql
|
||
+ [sql] [bug] Fixed multiple observed race conditions related to
|
||
lambda_stmt(), including an initial “dogpile” issue when a new
|
||
Python code object is initially analyzed among multiple
|
||
simultaneous threads which created both a performance issue as
|
||
well as some internal corruption of state. Additionally repaired
|
||
observed race condition which could occur when “cloning” an
|
||
expression construct that is also in the process of being
|
||
compiled or otherwise accessed in a different thread due to
|
||
memoized attributes altering the __dict__ while iterated, for
|
||
Python versions prior to 3.10; in particular the lambda SQL
|
||
construct is sensitive to this as it holds onto a single
|
||
statement object persistently. The iteration has been refined to
|
||
use dict.copy() with or without an additional iteration instead.
|
||
References: #8098
|
||
+ [sql] [bug] Enhanced the mechanism of Cast and other “wrapping”
|
||
column constructs to more fully preserve a wrapped Label
|
||
construct, including that the label name will be preserved in
|
||
the .c collection of a Subquery. The label was already able to
|
||
render in the SQL correctly on the outside of the construct
|
||
which it was wrapped inside. References: #8084
|
||
+ [sql] [bug] Adjusted the fix made for #8056 which adjusted the
|
||
escaping of bound parameter names with special characters such
|
||
that the escaped names were translated after the SQL compilation
|
||
step, which broke a published recipe on the FAQ illustrating how
|
||
to merge parameter names into the string output of a compiled
|
||
SQL string. The change restores the escaped names that come from
|
||
compiled.params and adds a conditional parameter to
|
||
SQLCompiler.construct_params() named escape_names that defaults
|
||
to True, restoring the old behavior by default. References:
|
||
#8113
|
||
* schema
|
||
+ [schema] [bug] Fixed bugs involving the Table.include_columns
|
||
and the Table.resolve_fks parameters on Table; these little-used
|
||
parameters were apparently not working for columns that refer to
|
||
foreign key constraints. In the first case, not-included
|
||
columns that refer to foreign keys would still attempt to create
|
||
a ForeignKey object, producing errors when attempting to resolve
|
||
the columns for the foreign key constraint within reflection;
|
||
foreign key constraints that refer to skipped columns are now
|
||
omitted from the table reflection process in the same way as
|
||
occurs for Index and UniqueConstraint objects with the same
|
||
conditions. No warning is produced however, as we likely want to
|
||
remove the include_columns warnings for all constraints in 2.0.
|
||
In the latter case, the production of table aliases or
|
||
subqueries would fail on an FK related table not found despite
|
||
the presence of resolve_fks=False; the logic has been repaired
|
||
so that if a related table is not found, the ForeignKey object
|
||
is still proxied to the aliased table or subquery (these
|
||
ForeignKey objects are normally used in the production of join
|
||
conditions), but it is sent with a flag that it’s not
|
||
resolvable. The aliased table / subquery will then work
|
||
normally, with the exception that it cannot be used to generate
|
||
a join condition automatically, as the foreign key information
|
||
is missing. This was already the behavior for such foreign key
|
||
constraints produced using non-reflection methods, such as
|
||
joining Table objects from different MetaData collections.
|
||
References: #8100, #8101
|
||
+ [schema] [bug] [mssql] Fixed issue where Table objects that made
|
||
use of IDENTITY columns with a Numeric datatype would produce
|
||
errors when attempting to reconcile the “autoincrement” column,
|
||
preventing construction of the Column from using the
|
||
Column.autoincrement parameter as well as emitting errors when
|
||
attempting to invoke an Insert construct. References: #8111
|
||
* extensions
|
||
+ [extensions] [bug] Fixed bug in Mutable where pickling and
|
||
unpickling of an ORM mapped instance would not correctly restore
|
||
state for mappings that contained multiple Mutable-enabled
|
||
attributes. References: #8133
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Jun 4 08:49:42 UTC 2022 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to 1.4.37
|
||
* details on https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-1.4.37
|
||
* Fixed issue where using a column_property() construct containing a subquery
|
||
against an already-mapped column attribute would not correctly apply
|
||
ORM-compilation behaviors to the subquery, including that the “IN” expression
|
||
added for a single-table inherits expression would fail to be included.
|
||
* Fixed issue where ORM results would apply incorrect key names to the
|
||
returned Row objects in the case where the set of columns to be selected
|
||
were changed, such as when using Select.with_only_columns().
|
||
* Fixed bug, likely a regression from 1.3, where usage of column names that
|
||
require bound parameter escaping, more concretely when using Oracle with
|
||
column names that require quoting such as those that start with an
|
||
underscore, or in less common cases with some PostgreSQL drivers when using
|
||
column names that contain percent signs, would cause the ORM versioning
|
||
feature to not work correctly if the versioning column itself had such a
|
||
name, as the ORM assumes certain bound parameter naming conventions that
|
||
were being interfered with via the quotes. This issue is related to #8053
|
||
and essentially revises the approach towards fixing this, revising the
|
||
original issue #5653 that created the initial implementation for
|
||
generalized bound-parameter name quoting.
|
||
|
||
-------------------------------------------------------------------
|
||
Wed May 4 19:54:39 UTC 2022 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to 1.4.36:
|
||
* details on https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-1.4.36
|
||
* Fixed regression where the change made for #7861, released in version
|
||
1.4.33, that brought the Insert construct to be partially recognized as an
|
||
ORM-enabled statement
|
||
* Modified the 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
|
||
* Fixed a memory leak in the C extensions which could occur when calling upon
|
||
named members of Row when the member does not exist under Python 3
|
||
* Added a warning regarding a bug which exists in the Result.columns() method
|
||
when passing 0 for the index in conjunction with a Result that will return
|
||
a single ORM entity, which indicates that the current behavior of
|
||
Result.columns() is broken in this case as the Result object will yield scalar
|
||
values and not Row objects
|
||
* Fixed bug where ForeignKeyConstraint naming conventions using the
|
||
referred_column_0 naming convention key would not work if the foreign key
|
||
constraint were set up as a ForeignKey object rather than an explicit
|
||
ForeignKeyConstraint object.
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Apr 20 08:25:03 UTC 2022 - pgajdos@suse.com
|
||
|
||
- python-mock is not required for build
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Apr 10 17:41:04 UTC 2022 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.4.35:
|
||
* sql
|
||
+ [sql] [bug] Fixed bug in newly implemented
|
||
FunctionElement.table_valued.joins_implicitly feature where the
|
||
parameter would not automatically propagate from the original
|
||
TableValuedAlias object to the secondary object produced when
|
||
calling upon TableValuedAlias.render_derived() or
|
||
TableValuedAlias.alias().
|
||
Additionally repaired these issues in TableValuedAlias:
|
||
- repaired a potential memory issue which could occur when
|
||
repeatedly calling TableValuedAlias.render_derived() against
|
||
successive copies of the same object (for .alias(), we
|
||
currently have to still continue chaining from the previous
|
||
element. not sure if this can be improved but this is standard
|
||
behavior for .alias() elsewhere)
|
||
- repaired issue where the individual element types would be
|
||
lost when calling upon TableValuedAlias.render_derived() or
|
||
TableValuedAlias.alias().
|
||
References: #7890
|
||
+ [sql] [bug] [regression] Fixed regression caused by #7823 which
|
||
impacted the caching system, such that bound parameters that had
|
||
been “cloned” within ORM operations, such as polymorphic
|
||
loading, would in some cases not acquire their correct
|
||
execution-time value leading to incorrect bind values being
|
||
rendered. References: #7903
|
||
|
||
- changes from version 1.4.34:
|
||
* orm
|
||
+ [orm] [bug] [regression] Fixed regression caused by #7861 where
|
||
invoking an Insert construct which contained ORM entities
|
||
directly via Session.execute() would fail. References: #7878
|
||
* postgresql
|
||
+ [postgresql] [bug] Scaled back a fix made for #6581 where
|
||
“executemany values” mode for psycopg2 were disabled for all “ON
|
||
CONFLICT” styles of INSERT, to not apply to the “ON CONFLICT DO
|
||
NOTHING” clause, which does not include any parameters and is
|
||
safe for “executemany values” mode. “ON CONFLICT DO UPDATE” is
|
||
still blocked from “executemany values” as there may be
|
||
additional parameters in the DO UPDATE clause that cannot be
|
||
batched (which is the original issue fixed by #6581).
|
||
References: #7880
|
||
|
||
- changes from version 1.4.33:
|
||
* orm
|
||
+ [orm] [usecase] Added with_polymorphic.adapt_on_names to the
|
||
with_polymorphic() function, which allows a polymorphic load
|
||
(typically with concrete mapping) to be stated against an
|
||
alternative selectable that will adapt to the original mapped
|
||
selectable on column names alone. References: #7805
|
||
+ [orm] [usecase] Added new attributes
|
||
UpdateBase.returning_column_descriptions and
|
||
UpdateBase.entity_description to allow for inspection of ORM
|
||
attributes and entities that are installed as part of an Insert,
|
||
Update, or Delete construct. The Select.column_descriptions
|
||
accessor is also now implemented for Core-only selectables.
|
||
References: #7861
|
||
+ [orm] [bug] [regression] Fixed regression in “dynamic” loader
|
||
strategy where the Query.filter_by() method would not be given
|
||
an appropriate entity to filter from, in the case where a
|
||
“secondary” table were present in the relationship being queried
|
||
and the mapping were against something complex such as a “with
|
||
polymorphic”. References: #7868
|
||
+ [orm] [bug] Fixed bug where composite() attributes would not
|
||
work in conjunction with the selectin_polymorphic() loader
|
||
strategy for joined table inheritance. References: #7801
|
||
+ [orm] [bug] [performance] Improvements in memory usage by the
|
||
ORM, removing a significant set of intermediary expression
|
||
objects that are typically stored when a copy of an expression
|
||
object is created. These clones have been greatly reduced,
|
||
reducing the number of total expression objects stored in memory
|
||
by ORM mappings by about 30%. References: #7823
|
||
+ [orm] [bug] Fixed issue where the selectin_polymorphic() loader
|
||
option would not work with joined inheritance mappers that don’t
|
||
have a fixed “polymorphic_on” column. Additionally added test
|
||
support for a wider variety of usage patterns with this
|
||
construct. References: #7799
|
||
+ [orm] [bug] Fixed bug in with_loader_criteria() function where
|
||
loader criteria would not be applied to a joined eager load that
|
||
were invoked within the scope of a refresh operation for the
|
||
parent object. References: #7862
|
||
+ [orm] [bug] Fixed issue where the Mapper would reduce a
|
||
user-defined Mapper.primary_key argument too aggressively, in
|
||
the case of mapping to a UNION where for some of the SELECT
|
||
entries, two columns are essentially equivalent, but in another,
|
||
they are not, such as in a recursive CTE. The logic here has
|
||
been changed to accept a given user-defined PK as given, where
|
||
columns will be related to the mapped selectable but no longer
|
||
“reduced” as this heuristic can’t accommodate for all
|
||
situations. References: #7842
|
||
* engine
|
||
+ [engine] [usecase] Added new parameter Engine.dispose.close,
|
||
defaulting to True. When False, the engine disposal does not
|
||
touch the connections in the old pool at all, simply dropping
|
||
the pool and replacing it. This use case is so that when the
|
||
original pool is transferred from a parent process, the parent
|
||
process may continue to use those connections.
|
||
See also
|
||
Using Connection Pools with Multiprocessing or os.fork() - revised documentation
|
||
References: #7815, #7877
|
||
+ [engine] [bug] Further clarified connection-level logging to
|
||
indicate the BEGIN, ROLLBACK and COMMIT log messages do not
|
||
actually indicate a real transaction when the AUTOCOMMIT
|
||
isolation level is in use; messaging has been extended to
|
||
include the BEGIN message itself, and the messaging has also
|
||
been fixed to accommodate when the Engine level
|
||
create_engine.isolation_level parameter was used directly.
|
||
References: #7853
|
||
* sql
|
||
+ [sql] [usecase] Added new parameter
|
||
FunctionElement.table_valued.joins_implicitly, for the
|
||
FunctionElement.table_valued() construct. This parameter
|
||
indicates that the given table-valued function implicitly joins
|
||
to the table it refers towards, essentially disabling the “from
|
||
linting” feature, i.e. the “cartesian product” warning, from
|
||
taking effect due to the presence of this parameter. May be used
|
||
for functions such as func.json_each(). References: #7845
|
||
+ [sql] [bug] The bindparam.literal_execute parameter now takes
|
||
part of the cache generation of a bindparam(), since it changes
|
||
the sql string generated by the compiler. Previously the correct
|
||
bind values were used, but the literal_execute would be ignored
|
||
on subsequent executions of the same query. References: #7876
|
||
+ [sql] [bug] [regression] Fixed regression caused by #7760 where
|
||
the new capabilities of TextualSelect were not fully implemented
|
||
within the compiler properly, leading to issues with composed
|
||
INSERT constructs such as “INSERT FROM SELECT” and “INSERT…ON
|
||
CONFLICT” when combined with CTE and textual statements.
|
||
References: #7798
|
||
* schema
|
||
+ [schema] [usecase] Added support so that the
|
||
Table.to_metadata.referred_schema_fn callable passed to
|
||
Table.to_metadata() may return the value BLANK_SCHEMA to
|
||
indicate that the referenced foreign key should be reset to
|
||
None. The RETAIN_SCHEMA symbol may also be returned from this
|
||
function to indicate “no change”, which will behave the same as
|
||
None currently does which also indicates no change. References:
|
||
#7860
|
||
* sqlite
|
||
+ [sqlite] [bug] [reflection] Fixed bug where the name of CHECK
|
||
constraints under SQLite would not be reflected if the name were
|
||
created using quotes, as is the case when the name uses mixed
|
||
case or special characters. References: #5463
|
||
* mssql
|
||
+ [mssql] [bug] [regression] Fixed regression caused by #7160
|
||
where FK reflection in conjunction with a low compatibility
|
||
level setting (compatibility level 80: SQL Server 2000) causes
|
||
an “Ambiguous column name” error. Patch courtesy @Lin-Your.
|
||
References: #7812
|
||
* misc
|
||
+ [bug] [ext] Improved the error message that’s raised for the
|
||
case where the association_proxy() construct attempts to access
|
||
a target attribute at the class level, and this access
|
||
fails. The particular use case here is when proxying to a hybrid
|
||
attribute that does not include a working class-level
|
||
implementation. References: #7827
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Mar 12 05:44:28 UTC 2022 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.4.32:
|
||
* orm
|
||
+ [orm] [bug] [regression] Fixed regression where the ORM
|
||
exception that is to be raised when an INSERT silently fails to
|
||
actually insert a row (such as from a trigger) would not be
|
||
reached, due to a runtime exception raised ahead of time due to
|
||
the missing primary key value, thus raising an uninformative
|
||
exception rather than the correct one. For 1.4 and above, a new
|
||
FlushError is added for this case that’s raised earlier than the
|
||
previous “null identity” exception was for 1.3, as a situation
|
||
where the number of rows actually INSERTed does not match what
|
||
was expected is a more critical situation in 1.4 as it prevents
|
||
batching of multiple objects from working correctly. This is
|
||
separate from the case where a newly fetched primary key is
|
||
fetched as NULL, which continues to raise the existing “null
|
||
identity” exception. References: #7594
|
||
+ [orm] [bug] Fixed issue where using a fully qualified path for
|
||
the classname in relationship() that nonetheless contained an
|
||
incorrect name for path tokens that were not the first token,
|
||
would fail to raise an informative error and would instead fail
|
||
randomly at a later step. References: #7697
|
||
* engine
|
||
+ [engine] [bug] Adjusted the logging for key SQLAlchemy
|
||
components including Engine, Connection to establish an
|
||
appropriate stack level parameter, so that the Python logging
|
||
tokens funcName and lineno when used in custom logging
|
||
formatters will report the correct information, which can be
|
||
useful when filtering log output; supported on Python 3.8 and
|
||
above. Pull request courtesy Markus Gerstel. References: #7612
|
||
* sql
|
||
+ [sql] [bug] Fixed type-related error messages that would fail
|
||
for values that were tuples, due to string formatting syntax,
|
||
including compile of unsupported literal values and invalid
|
||
boolean values. References: #7721
|
||
+ [sql] [bug] [mysql] Fixed issues in MySQL SET datatype as well
|
||
as the generic Enum datatype where the __repr__() method would
|
||
not render all optional parameters in the string output,
|
||
impacting the use of these types in Alembic autogenerate. Pull
|
||
request for MySQL courtesy Yuki Nishimine. References: #7598,
|
||
#7720, #7789
|
||
+ [sql] [bug] The Enum datatype now emits a warning if the
|
||
Enum.length argument is specified without also specifying
|
||
Enum.native_enum as False, as the parameter is otherwise
|
||
silently ignored in this case, despite the fact that the Enum
|
||
datatype will still render VARCHAR DDL on backends that don’t
|
||
have a native ENUM datatype such as SQLite. This behavior may
|
||
change in a future release so that “length” is honored for all
|
||
non-native “enum” types regardless of the “native_enum” setting.
|
||
+ [sql] [bug] Fixed issue where the HasCTE.add_cte() method as
|
||
called upon a TextualSelect instance was not being accommodated
|
||
by the SQL compiler. The fix additionally adds more
|
||
“SELECT”-like compiler behavior to TextualSelect including that
|
||
DML CTEs such as UPDATE and INSERT may be accommodated.
|
||
References: #7760
|
||
* asyncio
|
||
+ [asyncio] [bug] Fixed issues where a descriptive error message
|
||
was not raised for some classes of event listening with an async
|
||
engine, which should instead be a sync engine instance.
|
||
+ [asyncio] [bug] Fixed issue where the AsyncSession.execute()
|
||
method failed to raise an informative exception if the
|
||
Connection.execution_options.stream_results execution option
|
||
were used, which is incompatible with a sync-style Result object
|
||
when using an asyncio calling style, as the operation to fetch
|
||
more rows would need to be awaited. An exception is now raised
|
||
in this scenario in the same way one was already raised when the
|
||
Connection.execution_options.stream_results option would be used
|
||
with the AsyncConnection.execute() method. Additionally, for
|
||
improved stability with state-sensitive database drivers such as
|
||
asyncmy, the cursor is now closed when this error condition is
|
||
raised; previously with the asyncmy dialect, the connection
|
||
would go into an invalid state with unconsumed server side
|
||
results remaining. References: #7667
|
||
* postgresql
|
||
+ [postgresql] [usecase] Added compiler support for the PostgreSQL
|
||
NOT VALID phrase when rendering DDL for the CheckConstraint,
|
||
ForeignKeyConstraint and ForeignKey schema constructs. Pull
|
||
request courtesy Gilbert Gilb’s. References: #7600
|
||
* mysql
|
||
+ [mysql] [bug] [regression] Fixed regression caused by #7518
|
||
where changing the syntax “SHOW VARIABLES” to “SELECT @@” broke
|
||
compatibility with MySQL versions older than 5.6, including
|
||
early 5.0 releases. While these are very old MySQL versions, a
|
||
change in compatibility was not planned, so version-specific
|
||
logic has been restored to fall back to “SHOW VARIABLES” for
|
||
MySQL server versions < 5.6. References: #7518
|
||
* mariadb
|
||
+ [mariadb] [bug] [regression] Fixed regression in
|
||
mariadbconnector dialect as of mariadb connector 1.0.10 where
|
||
the DBAPI no longer pre-buffers cursor.lastrowid, leading to
|
||
errors when inserting objects with the ORM as well as causing
|
||
non-availability of the CursorResult.inserted_primary_key
|
||
attribute. The dialect now fetches this value proactively for
|
||
situations where it applies. References: #7738
|
||
* sqlite
|
||
+ [sqlite] [usecase] Added support for reflecting SQLite inline
|
||
unique constraints where the column names are formatted with
|
||
SQLite “escape quotes” [] or `, which are discarded by the
|
||
database when producing the column name. References: #7736
|
||
+ [sqlite] [bug] Fixed issue where SQLite unique constraint
|
||
reflection would fail to detect a column-inline UNIQUE
|
||
constraint where the column name had an underscore in its name.
|
||
References: #7736
|
||
* oracle
|
||
+ [oracle] [bug] Fixed issue in Oracle dialect where using a
|
||
column name that requires quoting when written as a bound
|
||
parameter, such as "_id", would not correctly track a Python
|
||
generated default value due to the bound-parameter rewriting
|
||
missing this value, causing an Oracle error to be raised.
|
||
References: #7676
|
||
+ [oracle] [bug] [regression] Added support to parse “DPI” error
|
||
codes from cx_Oracle exception objects such as DPI-1080 and
|
||
DPI-1010, both of which now indicate a disconnect scenario as of
|
||
cx_Oracle 8.3. References: #7748
|
||
* tests
|
||
+ [tests] [bug] Improvements to the test suite’s integration with
|
||
pytest such that the “warnings” plugin, if manually enabled,
|
||
will not interfere with the test suite, such that third parties
|
||
can enable the warnings plugin or make use of the -W parameter
|
||
and SQLAlchemy’s test suite will continue to pass. Additionally,
|
||
modernized the detection of the “pytest-xdist” plugin so that
|
||
plugins can be globally disabled using
|
||
PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 without breaking the test suite
|
||
if xdist were still installed. Warning filters that promote
|
||
deprecation warnings to errors are now localized to
|
||
SQLAlchemy-specific warnings, or within SQLAlchemy-specific
|
||
sources for general Python deprecation warnings, so that
|
||
non-SQLAlchemy deprecation warnings emitted from pytest plugins
|
||
should also not impact the test suite. References: #7599
|
||
+ [tests] [bug] Made corrections to the default pytest
|
||
configuration regarding how test discovery is configured, to fix
|
||
issue where the test suite would not configure warnings
|
||
correctly and also attempt to load example suites as tests, in
|
||
the specific case where the SQLAlchemy checkout were located in
|
||
an absolute path that had a super-directory named “test”.
|
||
References: #7045
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Jan 29 17:32:34 UTC 2022 - Arun Persaud <arun@gmx.de>
|
||
|
||
- specfile:
|
||
* update copyright year
|
||
|
||
- update to version 1.4.31:
|
||
* orm
|
||
+ [orm] [bug] Fixed issue in Session.bulk_save_objects() where the
|
||
sorting that takes place when the preserve_order parameter is
|
||
set to False would sort partially on Mapper objects, which is
|
||
rejected in Python 3.11. References: #7591
|
||
* postgresql
|
||
+ [postgresql] [bug] [regression] Fixed regression where the
|
||
change in #7148 to repair ENUM handling in PostgreSQL broke the
|
||
use case of an empty ARRAY of ENUM, preventing rows that
|
||
contained an empty array from being handled correctly when
|
||
fetching results. References: #7590
|
||
* mysql
|
||
+ [mysql] [bug] [regression] Fixed regression in asyncmy dialect
|
||
caused by #7567 where removal of the PyMySQL dependency broke
|
||
binary columns, due to the asyncmy dialect not being properly
|
||
included within CI tests. References: #7593
|
||
* mssql
|
||
+ [mssql] Added support for FILESTREAM when using VARBINARY(max)
|
||
in MSSQL. References: #7243
|
||
|
||
- changes from version 1.4.30:
|
||
* orm
|
||
+ [orm] [bug] Fixed issue in joined-inheritance load of additional
|
||
attributes functionality in deep multi-level inheritance where
|
||
an intermediary table that contained no columns would not be
|
||
included in the tables joined, instead linking those tables to
|
||
their primary key identifiers. While this works fine, it
|
||
nonetheless in 1.4 began producing the cartesian product
|
||
compiler warning. The logic has been changed so that these
|
||
intermediary tables are included regardless. While this does
|
||
include additional tables in the query that are not technically
|
||
necessary, this only occurs for the highly unusual case of deep
|
||
3+ level inheritance with intermediary tables that have no non
|
||
primary key columns, potential performance impact is therefore
|
||
expected to be negligible. References: #7507
|
||
+ [orm] [bug] Fixed issue where calling upon
|
||
registry.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 mapper() function which does report an
|
||
informative message already. References: #7579
|
||
+ [orm] [bug] [asyncio] Added missing method
|
||
AsyncSession.invalidate() to the AsyncSession class.
|
||
References: #7524
|
||
+ [orm] [bug] [regression] Fixed regression which appeared in
|
||
1.4.23 which could cause loader options to be mis-handled in
|
||
some cases, in particular when using joined table inheritance in
|
||
combination with the polymorphic_load="selectin" option as well
|
||
as relationship lazy loading, leading to a TypeError.
|
||
References: #7557
|
||
+ [orm] [bug] [regression] Fixed ORM regression where calling the
|
||
aliased() function against an existing aliased() construct would
|
||
fail to produce correct SQL if the existing construct were
|
||
against a fixed table. The fix allows that the original
|
||
aliased() construct is disregarded if it were only against a
|
||
table that’s now being replaced. It also allows for correct
|
||
behavior when constructing a aliased() without a selectable
|
||
argument against a aliased() that’s against a subuquery, to
|
||
create an alias of that subquery (i.e. to change its name). The
|
||
nesting behavior of aliased() remains in place for the case
|
||
where the outer aliased() object is against a subquery which in
|
||
turn refers to the inner aliased() object. This is a relatively
|
||
new 1.4 feature that helps to suit use cases that were
|
||
previously served by the deprecated Query.from_self() method.
|
||
References: #7576
|
||
+ [orm] [bug] Fixed issue where Select.correlate_except() method,
|
||
when passed either the None value or no arguments, would not
|
||
correlate any elements when used in an ORM context (that is,
|
||
passing ORM entities as FROM clauses), rather than causing all
|
||
FROM elements to be considered as “correlated” in the same way
|
||
which occurs when using Core-only constructs. References: #7514
|
||
+ [orm] [bug] [regression] Fixed regression from 1.3 where the
|
||
“subqueryload” loader strategy would fail with a stack trace if
|
||
used against a query that made use of Query.from_statement() or
|
||
Select.from_statement(). As subqueryload requires modifying the
|
||
original statement, it’s not compatible with the
|
||
“from_statement” use case, especially for statements made
|
||
against the text() construct. The behavior now is equivalent to
|
||
that of 1.3 and previously, which is that the loader strategy
|
||
silently degrades to not be used for such statements, typically
|
||
falling back to using the lazyload strategy. References: #7505
|
||
* sql
|
||
+ [sql] [bug] [postgresql] Added additional rule to the system
|
||
that determines TypeEngine implementations from Python literals
|
||
to apply a second level of adjustment to the type, so that a
|
||
Python datetime with or without tzinfo can set the timezone=True
|
||
parameter on the returned DateTime object, as well as Time. This
|
||
helps with some round-trip scenarios on type-sensitive
|
||
PostgreSQL dialects such as asyncpg, psycopg3 (2.0 only).
|
||
References: #7537
|
||
+ [sql] [bug] Added an informative error message when a method
|
||
object is passed to a SQL construct. Previously, when such a
|
||
callable were passed, as is a common typographical error when
|
||
dealing with method-chained SQL constructs, they were
|
||
interpreted as “lambda SQL” targets to be invoked at compilation
|
||
time, which would lead to silent failures. As this feature was
|
||
not intended to be used with methods, method objects are now
|
||
rejected. References: #7032
|
||
* mypy
|
||
+ [mypy] [bug] Fixed Mypy crash when running id daemon mode caused
|
||
by a missing attribute on an internal mypy Var instance.
|
||
References: #7321
|
||
* asyncio
|
||
+ [asyncio] [usecase] Added new method
|
||
AdaptedConnection.run_async() to the DBAPI connection interface
|
||
used by asyncio drivers, which allows methods to be called
|
||
against the underlying “driver” connection directly within a
|
||
sync-style function where the await keyword can’t be used, such
|
||
as within SQLAlchemy event handler functions. The method is
|
||
analogous to the AsyncConnection.run_sync() method which
|
||
translates async-style calls to sync-style. The method is useful
|
||
for things like connection-pool on-connect handlers that need to
|
||
invoke awaitable methods on the driver connection when it’s
|
||
first created. References: #7580
|
||
* postgresql
|
||
+ [postgresql] [usecase] Added string rendering to the UUID
|
||
datatype, so that stringifying a statement with “literal_binds”
|
||
that uses this type will render an appropriate string value for
|
||
the PostgreSQL backend. Pull request courtesy José Duarte.
|
||
References: #7561
|
||
+ [postgresql] [bug] [asyncpg] Improved support for asyncpg
|
||
handling of TIME WITH TIMEZONE, which was not fully implemented.
|
||
References: #7537
|
||
+ [postgresql] [bug] [mssql] [reflection] Fixed reflection of
|
||
covering indexes to report include_columns as part of the
|
||
dialect_options entry in the reflected index dictionary, thereby
|
||
enabling round trips from reflection->create to be
|
||
complete. Included columns continue to also be present under the
|
||
include_columns key for backwards compatibility. References:
|
||
#7382
|
||
+ [postgresql] [bug] Fixed handling of array of enum values which
|
||
require escape characters. References: #7418
|
||
+ mysql
|
||
+ [mysql] [change] Replace SHOW VARIABLES LIKE statement with
|
||
equivalent SELECT @@variable in MySQL and MariaDB dialect
|
||
initialization. This should avoid mutex contention caused by
|
||
SHOW VARIABLES, improving initialization performance.
|
||
References: #7518
|
||
+ [mysql] [bug] Removed unnecessary dependency on PyMySQL from the
|
||
asyncmy dialect. Pull request courtesy long2ice. References:
|
||
#7567
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Dec 27 12:32:23 UTC 2021 - Matej Cepl <mcepl@suse.com>
|
||
|
||
- Update to 1.4.29:
|
||
- truly, just plenty of small bugfixes, see the changelog on the Web
|
||
https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-1.4.29
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Dec 18 19:34:16 UTC 2021 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to 1.4.28:
|
||
Bugfixes, see
|
||
* https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-1.4.28
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Dec 5 19:11:39 UTC 2021 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to 1.4.27:
|
||
Bugfixes
|
||
* see https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html#change-1.4.27
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Oct 27 19:23:55 UTC 2021 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to version 1.4.26:
|
||
* a repair to the workings of the update() statement in an ORM context when
|
||
used with hybrid and composite attributes.
|
||
* Fixes for the with_loader_criteria() ORM option
|
||
* adjustments to the ORM Session interface to accommodate for new API features
|
||
* some new legacy warnings for lesser used patterns with Query.join()
|
||
* SQL / ORM fixes for the use case of selecting from repeated, non-labeled
|
||
column expressions, typically the null() construct when used as a
|
||
placeholder in a UNION statement.
|
||
* For PostgreSQL, refinements to the "expanding IN" SQL feature when used
|
||
with PostgreSQL ARRAY datatypes as well as fixes for the mostly
|
||
PostgreSQL-specific any_() and all_() column methods.
|
||
* For MySQL, repaired support for new behaviors in MariaDB 10.6
|
||
* For SQL Server, reflection fixes and improvements for foreign key
|
||
constraints as well table /view detection.
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Oct 16 23:34:51 UTC 2021 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to version 1.4.25:
|
||
* Fixed regression due to :ticket:`7024` where the reorganization of the
|
||
"platform machine" names used by the ``greenlet`` dependency mis-spelled
|
||
"aarch64" and additionally omitted uppercase "AMD64" as is needed for
|
||
Windows machines.
|
||
* Fixed a bug in :meth:`_asyncio.AsyncSession.execute` and
|
||
:meth:`_asyncio.AsyncSession.stream` that required ``execution_options``
|
||
to be an instance of ``immutabledict`` when defined. It now
|
||
correctly accepts any mapping.
|
||
* Improve the interface used by adapted drivers, like the asyncio ones,
|
||
to access the actual connection object returned by the driver.
|
||
* Implemented missing methods in :class:`_functions.FunctionElement` which,
|
||
while unused, would lead pylint to report them as unimplemented abstract
|
||
methods.
|
||
* Fixed an issue where :meth:`_reflection.has_table` returned
|
||
``True`` for local temporary tables that actually belonged to a
|
||
different SQL Server session (connection). An extra check is now
|
||
performed to ensure that the temp table detected is in fact owned
|
||
by the current session.
|
||
* Fixed issue where the ability of the
|
||
:meth:`_events.ConnectionEvents.before_execute` method to alter the SQL
|
||
statement object passed, returning the new object to be invoked, was
|
||
inadvertently removed. This behavior has been restored.
|
||
* Ensure that ``str()`` is called on the an
|
||
:paramref:`_url.URL.create.password` argument, allowing usage of objects
|
||
that implement the ``__str__()`` method as password attributes. Also
|
||
clarified that one such object is not appropriate to dynamically change the
|
||
password for each database connection; the approaches at
|
||
:ref:`engines_dynamic_tokens` should be used instead.
|
||
* Fixed ORM issue where column expressions passed to ``query()`` or
|
||
ORM-enabled ``select()`` would be deduplicated on the identity of the
|
||
object, such as a phrase like ``select(A.id, null(), null())`` would
|
||
produce only one "NULL" expression, which previously was not the case in
|
||
1.3. However, the change also allows for ORM expressions to render as given
|
||
as well, such as ``select(A.data, A.data)`` will produce a result row with
|
||
two columns.
|
||
* Fixed issue where mypy plugin would crash when interpreting a
|
||
``query_expression()`` construct.
|
||
* Added new methods :meth:`_orm.Session.scalars`,
|
||
* Added loader options to :meth:`_orm.Session.merge` and
|
||
:meth:`_asyncio.AsyncSession.merge` via a new
|
||
:paramref:`_orm.Session.merge.options` parameter, which will apply the
|
||
given loader options to the ``get()`` used internally by merge, allowing
|
||
eager loading of relationships etc. to be applied when the merge process
|
||
loads a new object. Pull request courtesy Daniel Stone.
|
||
* Added initial support for the ``asyncmy`` asyncio database driver for MySQL
|
||
and MariaDB. This driver is very new, however appears to be the only
|
||
current alternative to the ``aiomysql`` driver which currently appears to
|
||
be unmaintained and is not working with current Python versions. Much
|
||
thanks to long2ice for the pull request for this dialect.
|
||
* Fixed a two issues where combinations of ``select()`` and ``join()`` when
|
||
adapted to form a copy of the element would not completely copy the state
|
||
of all column objects associated with subqueries. A key problem this caused
|
||
is that usage of the :meth:`_sql.ClauseElement.params` method (which should
|
||
probably be moved into a legacy category as it is inefficient and error
|
||
prone) would leave copies of the old :class:`_sql.BindParameter` objects
|
||
around, leading to issues in correctly setting the parameters at execution
|
||
time.
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Jul 22 01:35:15 UTC 2021 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.4.22:
|
||
* orm
|
||
+ Fixed issue in new Table.table_valued() method where the
|
||
resulting TableValuedColumn construct would not respond
|
||
correctly to alias adaptation as is used throughout the ORM,
|
||
such as for eager loading, polymorphic loading, etc.
|
||
+ Fixed issue where usage of the Result.unique() method with an
|
||
ORM result that included column expressions with unhashable
|
||
types, such as JSON or ARRAY using non-tuples would silently
|
||
fall back to using the id() function, rather than raising an
|
||
error. This now raises an error when the Result.unique() method
|
||
is used in a 2.0 style ORM query. Additionally, hashability is
|
||
assumed to be True for result values of unknown type, such as
|
||
often happens when using SQL functions of unknown return type;
|
||
if values are truly not hashable then the hash() itself will
|
||
raise.
|
||
+ For legacy ORM queries, since the legacy Query object uniquifies
|
||
in all cases, the old rules remain in place, which is to use
|
||
id() for result values of unknown type as this legacy uniquing
|
||
is mostly for the purpose of uniquing ORM entities and not
|
||
column values.
|
||
+ Fixed an issue where clearing of mappers during things like test
|
||
suite teardowns could cause a “dictionary changed size” warning
|
||
during garbage collection, due to iteration of a
|
||
weak-referencing dictionary. A list() has been applied to
|
||
prevent concurrent GC from affecting this operation.
|
||
+ Fixed critical caching issue where the ORM’s persistence feature
|
||
using INSERT..RETURNING would cache an incorrect query when
|
||
mixing the “bulk save” and standard “flush” forms of INSERT.
|
||
* engine
|
||
+ Added some guards against KeyError in the event system to
|
||
accommodate the case that the interpreter is shutting down at
|
||
the same time Engine.dispose() is being called, which would
|
||
cause stack trace warnings.
|
||
* sql
|
||
+ Fixed issue where use of the case.whens parameter passing a
|
||
dictionary positionally and not as a keyword argument would emit
|
||
a 2.0 deprecation warning, referring to the deprecation of
|
||
passing a list positionally. The dictionary format of “whens”,
|
||
passed positionally, is still supported and was accidentally
|
||
marked as deprecated.
|
||
+ Fixed issue where type-specific bound parameter handlers would
|
||
not be called upon in the case of using the Insert.values()
|
||
method with the Python None value; in particular, this would be
|
||
noticed when using the JSON datatype as well as related
|
||
PostgreSQL specific types such as JSONB which would fail to
|
||
encode the Python None value into JSON null, however the issue
|
||
was generalized to any bound parameter handler in conjunction
|
||
with this specific method of Insert.
|
||
|
||
- changes from version 1.4.21:
|
||
* orm
|
||
+ Modified the approach used for history tracking of scalar object
|
||
relationships that are not many-to-one, i.e. one-to-one
|
||
relationships that would otherwise be one-to-many. When
|
||
replacing a one-to-one value, the “old” value that would be
|
||
replaced is no longer loaded immediately, and is instead handled
|
||
during the flush process. This eliminates an historically
|
||
troublesome lazy load that otherwise often occurs when assigning
|
||
to a one-to-one attribute, and is particularly troublesome when
|
||
using “lazy=’raise’” as well as asyncio use cases.
|
||
+ This change does cause a behavioral change within the
|
||
AttributeEvents.set() event, which is nonetheless currently
|
||
documented, which is that the event applied to such a one-to-one
|
||
attribute will no longer receive the “old” parameter if it is
|
||
unloaded and the relationship.active_history flag is not set. As
|
||
is documented in AttributeEvents.set(), if the event handler
|
||
needs to receive the “old” value when the event fires off, the
|
||
active_history flag must be established either with the event
|
||
listener or with the relationship. This is already the behavior
|
||
with other kinds of attributes such as many-to-one and column
|
||
value references.
|
||
+ The change additionally will defer updating a backref on the
|
||
“old” value in the less common case that the “old” value is
|
||
locally present in the session, but isn’t loaded on the
|
||
relationship in question, until the next flush occurs. If this
|
||
causes an issue, again the normal relationship.active_history
|
||
flag can be set to True on the relationship.
|
||
+ Fixed regression caused in 1.4.19 due to #6503 and related
|
||
involving Query.with_entities() where the new structure used
|
||
would be inappropriately transferred to an enclosing Query when
|
||
making use of set operations such as Query.union(), causing the
|
||
JOIN instructions within to be applied to the outside query as
|
||
well.
|
||
+ Fixed regression which appeared in version 1.4.3 due to #6060
|
||
where rules that limit ORM adaptation of derived selectables
|
||
interfered with other ORM-adaptation based cases, in this case
|
||
when applying adaptations for a with_polymorphic() against a
|
||
mapping which uses a column_property() which in turn makes use
|
||
of a scalar select that includes a aliased() object of the
|
||
mapped table.
|
||
+ Fixed ORM regression where ad-hoc label names generated for
|
||
hybrid properties and potentially other similar types of
|
||
ORM-enabled expressions would usually be propagated outwards
|
||
through subqueries, allowing the name to be retained in the
|
||
final keys of the result set even when selecting from
|
||
subqueries. Additional state is now tracked in this case that
|
||
isn’t lost when a hybrid is selected out of a Core select /
|
||
subquery.
|
||
* sql
|
||
+ Added new method HasCTE.add_cte() to each of the select(),
|
||
insert(), update() and delete() constructs. This method will add
|
||
the given CTE as an “independent” CTE of the statement, meaning
|
||
it renders in the WITH clause above the statement
|
||
unconditionally even if it is not otherwise referenced in the
|
||
primary statement. This is a popular use case on the PostgreSQL
|
||
database where a CTE is used for a DML statement that runs
|
||
against database rows independently of the primary statement.
|
||
+ Fixed issue in CTE constructs where a recursive CTE that
|
||
referred to a SELECT that has duplicate column names, which are
|
||
typically deduplicated using labeling logic in 1.4, would fail
|
||
to refer to the deduplicated label name correctly within the
|
||
WITH clause.
|
||
+ Fixed regression where the tablesample() construct would fail to
|
||
be executable when constructed given a floating-point sampling
|
||
value not embedded within a SQL function.
|
||
* postgresql
|
||
+ Fixed issue in Insert.on_conflict_do_nothing() and
|
||
Insert.on_conflict_do_update() where the name of a unique
|
||
constraint passed as the constraint parameter would not be
|
||
properly truncated for length if it were based on a naming
|
||
convention that generated a too-long name for the PostgreSQL max
|
||
identifier length of 63 characters, in the same way which occurs
|
||
within a CREATE TABLE statement.
|
||
+ Fixed issue where the PostgreSQL ENUM datatype as embedded in
|
||
the ARRAY datatype would fail to emit correctly in create/drop
|
||
when the schema_translate_map feature were also in
|
||
use. Additionally repairs a related issue where the same
|
||
schema_translate_map feature would not work for the ENUM
|
||
datatype in combination with a CAST, that’s also intrinsic to
|
||
how the ARRAY(ENUM) combination works on the PostgreSQL dialect.
|
||
+ Fixed issue in Insert.on_conflict_do_nothing() and
|
||
Insert.on_conflict_do_update() where the name of a unique
|
||
constraint passed as the constraint parameter would not be
|
||
properly quoted if it contained characters which required
|
||
quoting.
|
||
* mssql
|
||
+ Fixed regression where the special dotted-schema name handling
|
||
for the SQL Server dialect would not function correctly if the
|
||
dotted schema name were used within the schema_translate_map
|
||
feature.
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Jul 11 18:42:34 UTC 2021 - Antonio Larrosa <alarrosa@suse.com>
|
||
|
||
- update to version 1.4.20:
|
||
* orm
|
||
+ [orm] [bug] [regression] Fixed regression in ORM regarding
|
||
an internal reconstitution step for the with_polymorphic()
|
||
construct, when the user-facing object is garbage collected
|
||
as the query is processed. The reconstitution was not
|
||
ensuring the sub-entities for the “polymorphic” case were
|
||
handled, leading to an AttributeError.
|
||
References: #6680
|
||
+ [orm] [bug] [regression] Adjusted Query.union() and similar
|
||
set operations to be correctly compatible with the new
|
||
capabilities just added in #6661, with SQLAlchemy 1.4.19,
|
||
such that the SELECT statements rendered as elements of the
|
||
UNION or other set operation will include directly mapped
|
||
columns that are mapped as deferred; this both fixes a
|
||
regression involving unions with multiple levels of nesting
|
||
that would produce a column mismatch, and also allows the
|
||
undefer() option to be used at the top level of such a Query
|
||
without having to apply the option to each of the elements
|
||
within the UNION.
|
||
References: #6678
|
||
+ [orm] [bug] Adjusted the check in the mapper for a callable
|
||
object that is used as a @validates validator function or a
|
||
@reconstructor reconstruction function, to check for
|
||
“callable” more liberally such as to accommodate objects
|
||
based on fundamental attributes like __func__ and __call___,
|
||
rather than testing for MethodType / FunctionType, allowing
|
||
things like cython functions to work properly. Pull request
|
||
courtesy Miłosz Stypiński.
|
||
References: #6538
|
||
* engine
|
||
+ [engine] [bug] Fixed an issue in the C extension for the Row
|
||
class which could lead to a memory leak in the unlikely case
|
||
of a Row object which referred to an ORM object that then was
|
||
mutated to refer back to the Row itself, creating a cycle.
|
||
The Python C APIs for tracking GC cycles has been added to
|
||
the native Row implementation to accommodate for this case.
|
||
References: #5348
|
||
+ [engine] [bug] Fixed old issue where a select() made against
|
||
the token “*”, which then yielded exactly one column, would
|
||
fail to correctly organize the cursor.description column name
|
||
into the keys of the result object.
|
||
References: #6665
|
||
* sql
|
||
+ [sql] [usecase] Add a impl parameter to PickleType
|
||
constructor, allowing any arbitary type to be used in place
|
||
of the default implementation of LargeBinary. Pull request
|
||
courtesy jason3gb. References: #6646
|
||
+ [sql] [bug] [orm] Fixed the class hierarchy for the Sequence
|
||
and the more general DefaultGenerator base, as these are
|
||
“executable” as statements they need to include Executable
|
||
in their hierarchy, not just StatementRole as was applied
|
||
arbitrarily to Sequence previously. The fix allows Sequence
|
||
to work in all .execute() methods including with
|
||
Session.execute() which was not working in the case that a
|
||
SessionEvents.do_orm_execute() handler was also established.
|
||
References: #6668
|
||
* schema
|
||
+ [schema] [bug] Fixed issue where passing None for the value
|
||
of Table.prefixes would not store an empty list, but rather
|
||
the constant None, which may be unexpected by third party
|
||
dialects. The issue is revealed by a usage in recent versions
|
||
of Alembic that are passing None for this value. Pull request
|
||
courtesy Kai Mueller. References: #6685
|
||
* mysql
|
||
+ [mysql] [usecase] Made a small adjustment in the table
|
||
reflection feature of the MySQL dialect to accommodate for
|
||
alternate MySQL-oriented databases such as TiDB which include
|
||
their own “comment” directives at the end of a constraint
|
||
directive within “CREATE TABLE” where the format doesn’t have
|
||
the additional space character after the comment, in this
|
||
case the TiDB “clustered index” feature. Pull request
|
||
courtesy Daniël van Eeden. References: #6659
|
||
* misc
|
||
+ [bug] [ext] [regression] Fixed regression in
|
||
sqlalchemy.ext.automap extension such that the use case of
|
||
creating an explicit mapped class to a table that is also the
|
||
relationship.secondary element of a relationship() that
|
||
automap will be generating would emit the “overlaps” warnings
|
||
introduced in 1.4 and discussed at relationship X will copy
|
||
column Q to column P, which conflicts with relationship(s):
|
||
‘Y’. While generating this case from automap is still subject
|
||
to the same caveats that the “overlaps” warning refers
|
||
towards, as automap is intended for more ad-hoc use cases,
|
||
the condition which produces the warning is disabled when a
|
||
many-to-many relationship with this particular pattern is
|
||
generated. References: #6679
|
||
|
||
- changes from version 1.4.19:
|
||
* orm
|
||
+ [orm] [bug] [regression] Fixed further regressions in the
|
||
same area as that of #6052 where loader options as well as
|
||
invocations of methods like Query.join() would fail if the
|
||
left side of the statement for which the option/join depends
|
||
upon were replaced by using the Query.with_entities() method,
|
||
or when using 2.0 style queries when using the
|
||
Select.with_only_columns() method. A new set of state has
|
||
been added to the objects which tracks the “left” entities
|
||
that the options / join were made against which is memoized
|
||
when the lead entities are changed. References: #6253, #6503
|
||
+ [orm] [bug] Refined the behavior of ORM subquery rendering
|
||
with regards to deferred columns and column properties to be
|
||
more compatible with that of 1.3 while also providing for
|
||
1.4’s newer features. As a subquery in 1.4 does not make use
|
||
of loader options, including undefer(), a subquery that is
|
||
against an ORM entity with deferred attributes will now
|
||
render those deferred attributes that refer directly to
|
||
mapped table columns, as these are needed in the outer SELECT
|
||
if that outer SELECT makes use of these columns; however a
|
||
deferred attribute that refers to a composed SQL expression
|
||
as we normally do with column_property() will not be part of
|
||
the subquery, as these can be selected explicitly if needed
|
||
in the subquery. If the entity is being SELECTed from this
|
||
subquery, the column expression can still render on “the
|
||
outside” in terms of the derived subquery columns. This
|
||
produces essentially the same behavior as when working with
|
||
1.3. However in this case the fix has to also make sure that
|
||
the .selected_columns collection of an ORM-enabled select()
|
||
also follows these rules, which in particular allows
|
||
recursive CTEs to render correctly in this scenario, which
|
||
were previously failing to render correctly due to this
|
||
issue. References: #6661
|
||
* sql
|
||
+ [sql] [bug] Fixed issue in CTE constructs mostly relevant to
|
||
ORM use cases where a recursive CTE against “anonymous”
|
||
labels such as those seen in ORM column_property() mappings
|
||
would render in the WITH RECURSIVE xyz(...) section as their
|
||
raw internal label and not a cleanly anonymized name.
|
||
References: #6663
|
||
* mypy
|
||
+ [mypy] [bug] Fixed issue in mypy plugin where class info for
|
||
a custom declarative base would not be handled correctly on a
|
||
cached mypy pass, leading to an AssertionError being raised.
|
||
References: #6476
|
||
* asyncio
|
||
+ [asyncio] [usecase] Implemented async_scoped_session to
|
||
address some asyncio-related incompatibilities between
|
||
scoped_session and AsyncSession, in which some methods
|
||
(notably the async_scoped_session.remove() method) should
|
||
be used with the await keyword. References: #6583
|
||
+ [asyncio] [bug] [postgresql] Fixed bug in asyncio
|
||
implementation where the greenlet adaptation system failed
|
||
to propagate BaseException subclasses, most notably including
|
||
asyncio.CancelledError, to the exception handling logic used
|
||
by the engine to invalidate and clean up the connection, thus
|
||
preventing connections from being correctly disposed when a
|
||
task was cancelled. References: #6652
|
||
* postgresql
|
||
+ [postgresql] [bug] [oracle] Fixed issue where the INTERVAL
|
||
datatype on PostgreSQL and Oracle would produce an
|
||
AttributeError when used in the context of a comparison
|
||
operation against a timedelta() object. Pull request courtesy
|
||
MajorDallas. References: #6649
|
||
+ [postgresql] [bug] Fixed issue where the pool “pre ping”
|
||
feature would implicitly start a transaction, which would
|
||
then interfere with custom transactional flags such as
|
||
PostgreSQL’s “read only” mode when used with the psycopg2
|
||
driver. References: #6621
|
||
* mysql
|
||
+ [mysql] [usecase] Added new construct match, which provides
|
||
for the full range of MySQL’s MATCH operator including
|
||
multiple column support and modifiers. Pull request courtesy
|
||
Anton Kovalevich. References: #6132
|
||
* mssql
|
||
+ [mssql] [change] Made improvements to the server version
|
||
regexp used by the pymssql dialect to prevent a regexp
|
||
overflow in case of an invalid version string.
|
||
References: #6253, #6503
|
||
+ [mssql] [bug] Fixed bug where the “schema_translate_map”
|
||
feature would fail to function correctly in conjunction with
|
||
an INSERT into a table that has an IDENTITY column, where the
|
||
value of the IDENTITY column were specified in the values of
|
||
the INSERT thus triggering SQLAlchemy’s feature of setting
|
||
IDENTITY INSERT to “on”; it’s in this directive where the
|
||
schema translate map would fail to be honored.
|
||
References: #6658
|
||
|
||
- changes from version 1.4.18:
|
||
* orm
|
||
+ [orm] [performance] [bug] [regression] Fixed regression
|
||
involving how the ORM would resolve a given mapped column to
|
||
a result row, where under cases such as joined eager loading,
|
||
a slightly more expensive “fallback” could take place to set
|
||
up this resolution due to some logic that was removed since
|
||
1.3. The issue could also cause deprecation warnings
|
||
involving column resolution to be emitted when using a 1.4
|
||
style query with joined eager loading. References: #6596
|
||
+ [orm] [bug] Clarified the current purpose of the
|
||
relationship.bake_queries flag, which in 1.4 is to enable or
|
||
disable “lambda caching” of statements within the “lazyload”
|
||
and “selectinload” loader strategies; this is separate from
|
||
the more foundational SQL query cache that is used for most
|
||
statements. Additionally, the lazy loader no longer uses its
|
||
own cache for many-to-one SQL queries, which was an
|
||
implementation quirk that doesn’t exist for any other loader
|
||
scenario. Finally, the “lru cache” warning that the
|
||
lazyloader and selectinloader strategies could emit when
|
||
handling a wide array of class/relationship combinations has
|
||
been removed; based on analysis of some end-user cases, this
|
||
warning doesn’t suggest any significant issue. While setting
|
||
bake_queries=False for such a relationship will remove this
|
||
cache from being used, there’s no particular performance gain
|
||
in this case as using no caching vs. using a cache that needs
|
||
to refresh often likely still wins out on the caching being
|
||
used side. References: #6072, #6487
|
||
+ [orm] [bug] [regression] Adjusted the means by which classes
|
||
such as scoped_session and AsyncSession are generated from
|
||
the base Session class, such that custom Session subclasses
|
||
such as that used by Flask-SQLAlchemy don’t need to implement
|
||
positional arguments when they call into the superclass
|
||
method, and can continue using the same argument styles as in
|
||
previous releases. References: #6285
|
||
+ [orm] [bug] [regression] Fixed issue where query production
|
||
for joinedload against a complex left hand side involving
|
||
joined-table inheritance could fail to produce a correct
|
||
query, due to a clause adaption issue. References: #6595
|
||
+ [orm] [bug] Fixed issue in experimental “select ORM objects
|
||
from INSERT/UPDATE” use case where an error was raised if
|
||
the statement were against a single-table-inheritance
|
||
subclass. References: #6591
|
||
+ [orm] [bug] The warning that’s emitted for relationship()
|
||
when multiple relationships would overlap with each other as
|
||
far as foreign key attributes written towards, now includes
|
||
the specific “overlaps” argument to use for each warning in
|
||
order to silence the warning without changing the mapping.
|
||
References: #6400
|
||
* asyncio
|
||
+ [asyncio] [usecase] Implemented a new registry architecture
|
||
that allows the Async version of an object, like
|
||
AsyncSession, AsyncConnection, etc., to be locatable given
|
||
the proxied “sync” object, i.e. Session, Connection.
|
||
Previously, to the degree such lookup functions were used,
|
||
an Async object would be re-created each time, which was
|
||
less than ideal as the identity and state of the “async”
|
||
object would not be preserved across calls.
|
||
From there, new helper functions async_object_session(),
|
||
async_session() as well as a new InstanceState attribute
|
||
InstanceState.async_session have been added, which are used
|
||
to retrieve the original AsyncSession associated with an ORM
|
||
mapped object, a Session associated with an AsyncSession,
|
||
and an AsyncSession associated with an InstanceState,
|
||
respectively. This patch also implements new methods
|
||
AsyncSession.in_nested_transaction(),
|
||
AsyncSession.get_transaction(),
|
||
AsyncSession.get_nested_transaction(). References: #6319
|
||
+ [asyncio] [bug] Fixed an issue that presented itself when
|
||
using the NullPool or the StaticPool with an async engine.
|
||
This mostly affected the aiosqlite dialect.
|
||
References: #6575
|
||
+ [asyncio] [bug] Added asyncio.exceptions.TimeoutError,
|
||
asyncio.exceptions.CancelledError as so-called “exit
|
||
exceptions”, a class of exceptions that include things
|
||
like GreenletExit and KeyboardInterrupt, which are
|
||
considered to be events that warrant considering a DBAPI
|
||
connection to be in an unusable state where it should be
|
||
recycled. References: #6592
|
||
* postgresql
|
||
+ [postgresql] [bug] [regression] Fixed regression where using
|
||
the PostgreSQL “INSERT..ON CONFLICT” structure would fail to
|
||
work with the psycopg2 driver if it were used in an
|
||
“executemany” context along with bound parameters in the
|
||
“SET” clause, due to the implicit use of the psycopg2 fast
|
||
execution helpers which are not appropriate for this style of
|
||
INSERT statement; as these helpers are the default in 1.4
|
||
this is effectively a regression. Additional checks to
|
||
exclude this kind of statement from that particular extension
|
||
have been added. References: #6581
|
||
* sqlite
|
||
+ [sqlite] [bug] Add note regarding encryption-related pragmas
|
||
for pysqlcipher passed in the url. This change is also
|
||
backported to: 1.3.25. References: #6589
|
||
+ [sqlite] [bug] [regression] The fix for pysqlcipher released
|
||
in version 1.4.3 #5848 was unfortunately non-working, in that
|
||
the new on_connect_url hook was erroneously not receiving a
|
||
URL object under normal usage of create_engine() and instead
|
||
received a string that was unhandled; the test suite failed
|
||
to fully set up the actual conditions under which this hook
|
||
is called. This has been fixed. References: #6586
|
||
|
||
- changes from version 1.4.17:
|
||
* orm
|
||
+ [orm] [bug] [regression] Fixed regression caused by
|
||
just-released performance fix mentioned in #6550 where a
|
||
query.join() to a relationship could produce an
|
||
AttributeError if the query were made against non-ORM
|
||
structures only, a fairly unusual calling pattern.
|
||
References: #6558
|
||
|
||
- changes from version 1.4.16:
|
||
* general
|
||
+ [general] [bug] Resolved various deprecation warnings which
|
||
were appearing as of Python version 3.10.0b1.
|
||
References: #6540, #6543
|
||
* orm
|
||
+ [orm] [bug] Fixed issue when using
|
||
relationship.cascade_backrefs parameter set to False, which
|
||
per cascade_backrefs behavior deprecated for removal in 2.0
|
||
is set to become the standard behavior in SQLAlchemy 2.0,
|
||
where adding the item to a collection that uniquifies, such
|
||
as set or dict would fail to fire a cascade event if the
|
||
object were already associated in that collection via the
|
||
backref. This fix represents a fundamental change in the
|
||
collection mechanics by introducing a new event state which
|
||
can fire off for a collection mutation even if there is no
|
||
net change on the collection; the action is now suited using
|
||
a new event hook AttributeEvents.append_wo_mutation().
|
||
References: #6471
|
||
+ [orm] [bug] [regression] Fixed regression involving clause
|
||
adaption of labeled ORM compound elements, such as
|
||
single-table inheritance discriminator expressions with
|
||
conditionals or CASE expressions, which could cause aliased
|
||
expressions such as those used in ORM join / joinedload
|
||
operations to not be adapted correctly, such as referring
|
||
to the wrong table in the ON clause in a join.
|
||
This change also improves a performance bump that was located
|
||
within the process of invoking Select.join() given an ORM
|
||
attribute as a target. References: #6550
|
||
+ [orm] [bug] [regression] Fixed regression where the full
|
||
combination of joined inheritance, global with_polymorphic,
|
||
self-referential relationship and joined loading would fail
|
||
to be able to produce a query with the scope of lazy loads
|
||
and object refresh operations that also attempted to render
|
||
the joined loader. References: #6495
|
||
+ [orm] [bug] Enhanced the bind resolution rules for
|
||
Session.execute() so that when a non-ORM statement such as
|
||
an insert() construct nonetheless is built against ORM
|
||
objects, to the greatest degree possible the ORM entity will
|
||
be used to resolve the bind, such as for a Session that has
|
||
a bind map set up on a common superclass without specific
|
||
mappers or tables named in the map. References: #6484
|
||
* engine
|
||
+ [engine] [bug] Fixed issue where an @ sign in the database
|
||
portion of a URL would not be interpreted correctly if the
|
||
URL also had a username:password section. References: #6482
|
||
+ [engine] [bug] Fixed a long-standing issue with URL where
|
||
query parameters following the question mark would not be
|
||
parsed correctly if the URL did not contain a database
|
||
portion with a backslash. References: #6329
|
||
* sql
|
||
+ [sql] [bug] [regression] Fixed regression in dynamic loader
|
||
strategy and relationship() overall where the
|
||
relationship.order_by parameter were stored as a mutable
|
||
list, which could then be mutated when combined with
|
||
additional “order_by” methods used against the dynamic
|
||
query object, causing the ORDER BY criteria to continue
|
||
to grow repetitively. References: #6549
|
||
* mssql
|
||
+ [mssql] [usecase] Implemented support for a CTE construct to
|
||
be used directly as the target of a delete() construct, i.e.
|
||
“WITH … AS cte DELETE FROM cte”. This appears to be a useful
|
||
feature of SQL Server. References: #6464
|
||
* misc
|
||
+ [bug] [ext] Fixed a deprecation warning that was emitted
|
||
when using automap_base() without passing an existing Base.
|
||
References: #6529
|
||
+ [bug] [pep484] Remove pep484 types from the code. Current
|
||
effort is around the stub package, and having typing in two
|
||
places makes thing worse, since the types in the SQLAlchemy
|
||
source were usually outdated compared to the version in the
|
||
stubs. References: #6461
|
||
+ [bug] [ext] [regression] Fixed regression in the
|
||
sqlalchemy.ext.instrumentation extension that prevented
|
||
instrumentation disposal from working completely. This fix
|
||
includes both a 1.4 regression fix as well as a fix for a
|
||
related issue that existed in 1.3 also. As part of this
|
||
change, the
|
||
sqlalchemy.ext.instrumentation.InstrumentationManager class
|
||
now has a new method unregister(), which replaces the
|
||
previous method dispose(), which was not called as of
|
||
version 1.4. References: #6390
|
||
|
||
- Drop patch:
|
||
* tests_overcome_bpo42967.patch
|
||
|
||
-------------------------------------------------------------------
|
||
Fri May 14 01:05:31 UTC 2021 - Arun Persaud <arun@gmx.de>
|
||
|
||
- updated line numbers in patch
|
||
|
||
- update to version 1.4.15:
|
||
* general
|
||
+ [general] [feature] A new approach has been applied to the
|
||
warnings system in SQLAlchemy to accurately predict the
|
||
appropriate stack level for each warning dynamically. This
|
||
allows evaluating the source of SQLAlchemy-generated warnings
|
||
and deprecation warnings to be more straightforward as the
|
||
warning will indicate the source line within end-user code,
|
||
rather than from an arbitrary level within SQLAlchemy’s own
|
||
source code.
|
||
* orm
|
||
+ [orm] [bug] [regression] Fixed additional regression caused by
|
||
“eager loaders run on unexpire” feature #1763 where the feature
|
||
would run for a contains_eager() eagerload option in the case
|
||
that the contains_eager() were chained to an additional eager
|
||
loader option, which would then produce an incorrect query as
|
||
the original query-bound join criteria were no longer present.
|
||
+ [orm] [bug] Fixed issue in subquery loader strategy which
|
||
prevented caching from working correctly. This would have been
|
||
seen in the logs as a “generated” message instead of “cached”
|
||
for all subqueryload SQL emitted, which by saturating the cache
|
||
with new keys would degrade overall performance; it also would
|
||
produce “LRU size alert” warnings.
|
||
* sql
|
||
+ [sql] [bug] Adjusted the logic added as part of #6397 in 1.4.12
|
||
so that internal mutation of the BindParameter object occurs
|
||
within the clause construction phase as it did before, rather
|
||
than in the compilation phase. In the latter case, the mutation
|
||
still produced side effects against the incoming construct and
|
||
additionally could potentially interfere with other internal
|
||
mutation routines.
|
||
* mysql
|
||
+ [mysql] [bug] [documentation] Added support for the
|
||
ssl_check_hostname= parameter in mysql connection URIs and
|
||
updated the mysql dialect documentation regarding secure
|
||
connections. Original pull request courtesy of Jerry Zhao.
|
||
|
||
- changes from version 1.4.14:
|
||
* orm
|
||
+ [orm] [bug] [regression] Fixed regression involving
|
||
lazy='dynamic' loader in conjunction with a detached object. The
|
||
previous behavior was that the dynamic loader upon calling
|
||
methods like .all() returns empty lists for detached objects
|
||
without error, this has been restored; however a warning is now
|
||
emitted as this is not the correct result. Other dynamic loader
|
||
scenarios correctly raise DetachedInstanceError.
|
||
* engine
|
||
+ [engine] [usecase] [orm] Applied consistent behavior to the use
|
||
case of calling .commit() or .rollback() inside of an existing
|
||
.begin() context manager, with the addition of potentially
|
||
emitting SQL within the block subsequent to the commit or
|
||
rollback. This change continues upon the change first added in
|
||
#6155 where the use case of calling “rollback” inside of a
|
||
.begin() contextmanager block was proposed:
|
||
o calling .commit() or .rollback() will now be allowed without
|
||
error or warning within all scopes, including that of legacy
|
||
and future Engine, ORM Session, asyncio
|
||
AsyncEngine. Previously, the Session disallowed this.
|
||
o The remaining scope of the context manager is then closed;
|
||
when the block ends, a check is emitted to see if the
|
||
transaction was already ended, and if so the block returns
|
||
without action.
|
||
o It will now raise an error if subsequent SQL of any kind is
|
||
emitted within the block, after .commit() or .rollback() is
|
||
called. The block should be closed as the state of the
|
||
executable object would otherwise be undefined in this
|
||
state.
|
||
+ [engine] [bug] [regression] Established a deprecation path for
|
||
calling upon the CursorResult.keys() method for a statement that
|
||
returns no rows to provide support for legacy patterns used by
|
||
the “records” package as well as any other non-migrated
|
||
applications. Previously, this would raise
|
||
ResourceClosedException unconditionally in the same way as it
|
||
does when attempting to fetch rows. While this is the correct
|
||
behavior going forward, the _cursor.LegacyCursorResult object
|
||
will now in this case return an empty list for .keys() as it did
|
||
in 1.3, while also emitting a 2.0 deprecation warning. The
|
||
_cursor.CursorResult, used when using a 2.0-style “future”
|
||
engine, will continue to raise as it does now.
|
||
* sql
|
||
+ [sql] [bug] [regression] Fixed regression caused by the “empty
|
||
in” change just made in #6397 1.4.12 where the expression needs
|
||
to be parenthesized for the “not in” use case, otherwise the
|
||
condition will interfere with the other filtering criteria.
|
||
+ [sql] [bug] [regression] The TypeDecorator class will now emit a
|
||
warning when used in SQL compilation with caching unless the
|
||
.cache_ok flag is set to True or False. A new class-level
|
||
attribute TypeDecorator.cache_ok may be set which will be used
|
||
as an indication that all the parameters passed to the object
|
||
are safe to be used as a cache key if set to True, False means
|
||
they are not.
|
||
|
||
-------------------------------------------------------------------
|
||
Thu May 6 08:22:12 UTC 2021 - Antonio Larrosa <alarrosa@suse.com>
|
||
|
||
- Remove %ifpython2 (python2 flavor is disabled).
|
||
- Do not use %if %{python_version_nodots} for BuildRequires.
|
||
|
||
-------------------------------------------------------------------
|
||
Wed May 5 16:56:39 UTC 2021 - Antonio Larrosa <alarrosa@suse.com>
|
||
|
||
- Remove broken %ifpython3 since the python2 flavor is disabled
|
||
anyway.
|
||
|
||
-------------------------------------------------------------------
|
||
Tue May 4 08:30:21 UTC 2021 - Antonio Larrosa <alarrosa@suse.com>
|
||
|
||
- update to 1.4.13:
|
||
orm
|
||
* Fixed regression in selectinload loader strategy that would
|
||
cause it to cache its internal state incorrectly when handling
|
||
relationships that join across more than one column, such as
|
||
when using a composite foreign key. The invalid caching would
|
||
then cause other unrelated loader operations to fail.
|
||
References: #6410
|
||
* Fixed regression where Query.filter_by() would not work if the
|
||
lead entity were a SQL function or other expression derived
|
||
from the primary entity in question, rather than a simple
|
||
entity or column of that entity. Additionally, improved the
|
||
behavior of Select.filter_by() overall to work with column
|
||
expressions even in a non-ORM context. References: #6414
|
||
* Fixed regression where using selectinload() and subqueryload()
|
||
to load a two-level-deep path would lead to an attribute error.
|
||
References: #6419
|
||
* Fixed regression where using the noload() loader strategy in
|
||
conjunction with a “dynamic” relationship would lead to an
|
||
attribute error as the noload strategy would attempt to apply
|
||
itself to the dynamic loader. References: #6420
|
||
engine
|
||
* Restored a legacy transactional behavior that was inadvertently
|
||
removed from the Connection as it was never tested as a known
|
||
use case in previous versions, where calling upon the
|
||
Connection.begin_nested() method, when no transaction is
|
||
present, does not create a SAVEPOINT at all and instead starts
|
||
an outer transaction, returning a RootTransaction object
|
||
instead of a NestedTransaction object. This RootTransaction
|
||
then will emit a real COMMIT on the database connection when
|
||
committed. Previously, the 2.0 style behavior was present in
|
||
all cases that would autobegin a transaction but not commit
|
||
it, which is a behavioral change. When using a 2.0 style
|
||
connection object, the behavior is unchanged from previous
|
||
1.4 versions; calling Connection.begin_nested() will
|
||
“autobegin” the outer transaction if not already present,
|
||
and then as instructed emit a SAVEPOINT, returning the
|
||
NestedTransaction object. The outer transaction is committed
|
||
by calling upon Connection.commit(), as is “commit-as-you-go”
|
||
style usage.
|
||
In non-“future” mode, while the old behavior is restored,
|
||
it also emits a 2.0 deprecation warning as this is a legacy
|
||
behavior. References: #6408
|
||
asyncio
|
||
* Fixed a regression introduced by #6337 that would create an
|
||
asyncio.Lock which could be attached to the wrong loop when
|
||
instantiating the async engine before any asyncio loop was
|
||
started, leading to an asyncio error message when attempting
|
||
to use the engine under certain circumstances.
|
||
References: #6409
|
||
postgresql
|
||
* Add support for server side cursors in the pg8000 dialect
|
||
for PostgreSQL. This allows use of the
|
||
Connection.execution_options.stream_results option.
|
||
References: #6198
|
||
|
||
-------------------------------------------------------------------
|
||
Tue May 4 07:40:41 UTC 2021 - Antonio Larrosa <alarrosa@suse.com>
|
||
|
||
- Removed use of pytest-xdist which is giving intermitent
|
||
failed builds with internal errors like:
|
||
INTERNALERROR> E RuntimeError: There is no current
|
||
event loop in thread 'Dummy-1'.
|
||
[...]
|
||
INTERNALERROR> /usr/lib/python3.9/site-packages/xdist/
|
||
dsession.py:190: AssertionError
|
||
[gw6] node down: Not properly terminated
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Apr 30 09:06:50 UTC 2021 - Antonio Larrosa <alarrosa@suse.com>
|
||
|
||
- Update to 1.4.12 (bsc#1184038):
|
||
* There are many changes between the 1.4 and 1.3 branch so please
|
||
check the full list at:
|
||
https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html
|
||
* obsoletes sqlalchemy-7293b3dc0e9eb3dae84ffd831494b85355df8e73.patch
|
||
in older dists
|
||
|
||
- Update to the 1.4 branch:
|
||
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.
|
||
* Python 3.6 is the minimum Python 3 version; Python 2.7 still
|
||
supported
|
||
* ORM Query is internally unified with select, update, delete;
|
||
2.0 style execution available.
|
||
* Transparent SQL Compilation Caching added to All DQL,
|
||
DML Statements in Core, ORM.
|
||
* Declarative is now integrated into the ORM with new features
|
||
* Python Dataclasses, attrs Supported w/ Declarative,
|
||
Imperative Mappings.
|
||
* Asynchronous IO Support for Core and ORM
|
||
* Many Core and ORM statement objects now perform much of their
|
||
construction and validation in the compile phase
|
||
* Repaired internal importing conventions such that code linters
|
||
may work correctly
|
||
* Support for SQL Regular Expression operators
|
||
* SQLAlchemy 2.0 Deprecations Mode
|
||
* API and Behavioral Changes - Core
|
||
- A SELECT statement is no longer implicitly considered to be
|
||
a FROM clause
|
||
- select().join() and outerjoin() add JOIN criteria to the
|
||
current query, rather than creating a subquery
|
||
- The URL object is now immutable
|
||
- Changes to CreateEnginePlugin
|
||
- select(), case() now accept positional expressions
|
||
- All IN expressions render parameters for each value in the
|
||
list on the fly (e.g. expanding parameters)
|
||
- Built-in FROM linting will warn for any potential cartesian
|
||
products in a SELECT statement
|
||
- New Result object
|
||
- RowProxy is no longer a “proxy”; is now called Row and
|
||
behaves like an enhanced named tuple
|
||
- Rationale: To behave more like a named tuple rather than
|
||
a mapping
|
||
- Proxying behavior goes away, was also unnecessary in
|
||
modern usage
|
||
- SELECT objects and derived FROM clauses allow for duplicate
|
||
columns and column labels
|
||
- Improved column labeling for simple column expressions using
|
||
CAST or similar
|
||
- New "post compile" bound parameters used for LIMIT/OFFSET
|
||
in Oracle, SQL Server
|
||
- Connection-level transactions can now be inactive based on
|
||
subtransaction
|
||
- Enum and Boolean datatypes no longer default to "create
|
||
constraint"
|
||
* New Features - ORM
|
||
- Raiseload for Columns
|
||
- ORM Batch inserts with psycopg2 now batch statements with
|
||
RETURNING in most cases
|
||
- ORM Bulk Update and Delete use RETURNING for "fetch"
|
||
strategy when available
|
||
* Behavioral Changes - ORM
|
||
- The "KeyedTuple" object returned by Query is replaced by Row
|
||
- Session features new “autobegin” behavior
|
||
- Viewonly relationships don’t synchronize backrefs
|
||
- cascade_backrefs behavior deprecated for removal in 2.0
|
||
- Eager loaders emit during unexpire operations
|
||
- Accessing an uninitialized collection attribute on a
|
||
transient object no longer mutates __dict__
|
||
- The "New instance conflicts with existing identity" error
|
||
is now a warning
|
||
- Persistence-related cascade operations disallowed with
|
||
viewonly=True
|
||
- Stricter behavior when querying inheritance mappings using
|
||
custom queries
|
||
* Dialect Changes
|
||
- psycopg2 version 2.7 or higher is required for the
|
||
PostgreSQL psycopg2 dialect
|
||
- psycopg2 dialect no longer has limitations regarding bound
|
||
parameter names
|
||
- psycopg2 dialect features "execute_values" with RETURNING
|
||
for INSERT statements by default
|
||
- Removed “join rewriting” logic from SQLite dialect;
|
||
updated imports
|
||
- Added Sequence support for MariaDB 10.3
|
||
- Added Sequence support distinct from IDENTITY to SQL Server
|
||
* For an explanation of each of those changes, check
|
||
- https://docs.sqlalchemy.org/en/14/changelog/migration_14.html
|
||
|
||
- For the full list of changes in each revision in the 1.4 branch
|
||
please read:
|
||
* https://docs.sqlalchemy.org/en/14/changelog/changelog_14.html
|
||
|
||
- Do not build the python2 flavor. Python 2.7 is supposed to be
|
||
supported but currently fails to build.
|
||
|
||
- Rebase patch:
|
||
* tests_overcome_bpo42967.patch
|
||
|
||
-------------------------------------------------------------------
|
||
Tue Feb 23 17:27:18 UTC 2021 - Matej Cepl <mcepl@suse.com>
|
||
|
||
- Add tests_overcome_bpo42967.patch to over effects of bpo#42967,
|
||
which forbade mixing amps and semicolons in query strings as
|
||
separators (gh#sqlalchemy/sqlalchemy#5969).
|
||
|
||
-------------------------------------------------------------------
|
||
Tue Feb 23 17:07:02 UTC 2021 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to 1.3.23:
|
||
* Release 1.3.23 contains an array of bugfixes specific to dialects such as
|
||
Oracle, PostgreSQL, and MySQL.
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Jan 20 12:21:49 UTC 2021 - John Vandenberg <jayvdb@gmail.com>
|
||
|
||
- Skip one failing test on Python 3.6
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Dec 19 11:01:39 UTC 2020 - Dirk Müller <dmueller@suse.com>
|
||
|
||
- update to 1.3.22:
|
||
* Fixed regression which occured due to #5755 which implemented isolation
|
||
level support for Oracle
|
||
* bugfixes for various engines, see
|
||
https://docs.sqlalchemy.org/en/14/changelog/changelog_13.html#change-1.3.21
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Oct 19 07:04:45 UTC 2020 - Adrian Schröter <adrian@suse.de>
|
||
|
||
- added gpg pub key for source validation
|
||
- Update to version 1.3.20
|
||
pytest_depr_from_parent.patch is obsolete again
|
||
orm
|
||
* An ArgumentError with more detail is now raised if the target
|
||
parameter for Query.join() is set to an unmapped object. Prior
|
||
to this change a less detailed AttributeError was raised. Pull
|
||
request courtesy Ramon Williams. References: #4428
|
||
|
||
* Fixed issue where using a loader option against a string attribute
|
||
name that is not actually a mapped attribute, such as a plain
|
||
Python descriptor, would raise an uninformative AttributeError;
|
||
a descriptive error is now raised. References: #4589
|
||
|
||
engine
|
||
* Fixed issue where a non-string object sent to SQLAlchemyError or a
|
||
subclass, as occurs with some third party dialects, would fail to
|
||
stringify correctly. Pull request courtesy Andrzej Bartosiński.
|
||
References: #5599
|
||
|
||
* Repaired a function-level import that was not using SQLAlchemy’s
|
||
standard late-import system within the sqlalchemy.exc module.
|
||
References: #5632
|
||
|
||
sql
|
||
* Fixed issue where the pickle.dumps() operation against Over construct
|
||
would produce a recursion overflow. References: #5644
|
||
|
||
* Fixed bug where an error was not raised in the case where a column()
|
||
were added to more than one table() at a time. This raised correctly
|
||
for the Column and Table objects. An ArgumentError is now raised when
|
||
this occurs. References: #5618
|
||
|
||
postgresql
|
||
* The psycopg2 dialect now support PostgreSQL multiple host connections,
|
||
by passing host/port combinations to the query string.
|
||
References: #4392
|
||
|
||
* Adjusted the Comparator.any() and Comparator.all() methods to implement
|
||
a straight “NOT” operation for negation, rather than negating the
|
||
comparison operator. References: #5518
|
||
|
||
* Fixed issue where the ENUM type would not consult the schema translate
|
||
map when emitting a CREATE TYPE or DROP TYPE during the test to see if
|
||
the type exists or not. Additionally, repaired an issue where if the
|
||
same enum were encountered multiple times in a single DDL sequence,
|
||
the “check” query would run repeatedly rather than relying upon a cached value.
|
||
References: #5520
|
||
|
||
mysql
|
||
* Adjusted the MySQL dialect to correctly parenthesize functional index
|
||
expressions as accepted by MySQL 8. Pull request courtesy Ramon Williams.
|
||
References: #5462
|
||
|
||
* The “skip_locked” keyword used with with_for_update() will emit a warning
|
||
when used on MariaDB backends, and will then be ignored. This is a
|
||
deprecated behavior that will raise in SQLAlchemy 1.4, as an application
|
||
that requests “skip locked” is looking for a non-blocking operation which
|
||
is not available on those backends.
|
||
References: #5568
|
||
|
||
* Fixed bug where an UPDATE statement against a JOIN using MySQL multi-table
|
||
format would fail to include the table prefix for the target table if the
|
||
statement had no WHERE clause, as only the WHERE clause were scanned to
|
||
detect a “multi table update” at that particular point. The target is now
|
||
also scanned if it’s a JOIN to get the leftmost table as the primary table
|
||
and the additional entries as additional FROM entries.
|
||
References: #5617
|
||
|
||
* Add new MySQL reserved words: cube, lateral added in MySQL 8.0.1 and 8.0.14,
|
||
respectively; this indicates that these terms will be quoted if used as table
|
||
or column identifier names.
|
||
References: #5539
|
||
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Oct 9 13:02:39 UTC 2020 - Matej Cepl <mcepl@suse.com>
|
||
|
||
- Replace pytest_depr_from_parent.patch with the upstream commit resolving
|
||
same issue (gh#sqlalchemy/sqlalchemy#commit40cdb9c0bf4d).
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Oct 8 15:45:04 UTC 2020 - Matej Cepl <mcepl@suse.com>
|
||
|
||
- Add pytest_depr_from_parent.patch to fix FTBGS with pytest 6.*
|
||
(gh#sqlalchemy/sqlalchemy#5635)
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Aug 20 12:00:42 UTC 2020 - Ondřej Súkup <mimi.vx@gmail.com>
|
||
|
||
- update to 1.3.19
|
||
* Adjusted the workings of the Mapper.all_orm_descriptors()
|
||
* The name of the virtual column used when using the AbstractConcreteBase
|
||
and ConcreteBase classes can now be customized
|
||
* Repaired an issue where the “ORDER BY” clause rendering a label name rather
|
||
than a complete expression
|
||
* The LookupError message will now provide the user with up to four possible
|
||
values that a column is constrained to via the Enum
|
||
* Fixed issue where the Connection.execution_options.schema_translate_map
|
||
feature would not take effect when the Sequence.next_value() function
|
||
for a Sequence were used in the Column.server_default parameter
|
||
and the create table DDL were emitted.
|
||
* Added a **kw argument to the DeclarativeMeta.__init__() method
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Jun 28 18:53:41 UTC 2020 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.3.18:
|
||
* orm
|
||
+ Improve error message when using Query.filter_by() in a query
|
||
where the first entity is not a mapped class. References: #5326
|
||
+ Added a new parameter query_expression.default_expr to the
|
||
query_expression() construct, which will be appled to queries
|
||
automatically if the with_expression() option is not used. Pull
|
||
request courtesy Haoyu Sun. References: #5198
|
||
* engine
|
||
+ Further refinements to the fixes to the “reset” agent fixed in
|
||
#5326, which now emits a warning when it is not being correctly
|
||
invoked and corrects for the behavior. Additional scenarios have
|
||
been identified and fixed where this warning was being emitted.
|
||
References: #5326
|
||
+ Fixed issue in URL object where stringifying the object would
|
||
not URL encode special characters, preventing the URL from being
|
||
re-consumable as a real URL. Pull request courtesy Miguel
|
||
Grinberg. References: #5341
|
||
* sql
|
||
+ Added a “.schema” parameter to the table() construct, allowing
|
||
ad-hoc table expressions to also include a schema name. Pull
|
||
request courtesy Dylan Modesitt. References: #5309
|
||
+ Correctly apply self_group in type_coerce element. The type
|
||
coerce element did not correctly apply grouping rules when using
|
||
in an expression References: #5344
|
||
+ Added Select.with_hint() output to the generic SQL string that
|
||
is produced when calling str() on a statement. Previously, this
|
||
clause would be omitted under the assumption that it was dialect
|
||
specific. The hint text is presented within brackets to indicate
|
||
the rendering of such hints varies among backends. References:
|
||
#5353
|
||
+ Introduce IdentityOptions to store common parameters for
|
||
sequences and identity columns. References: #5324
|
||
+ Added .offset support to sybase dialect. Pull request courtesy
|
||
Alan D. Snow. References: #5294
|
||
* schema
|
||
+ Fixed issue where dialect_options were omitted when a database
|
||
object (e.g., Table) was copied using tometadata(). References:
|
||
#5276
|
||
* mysql
|
||
+ Implemented row-level locking support for mysql. Pull request
|
||
courtesy Quentin Somerville. References: #4860
|
||
* sqlite
|
||
+ SQLite 3.31 added support for computed column. This change
|
||
enables their support in SQLAlchemy when targeting SQLite.
|
||
References: #5297
|
||
+ Added “exists” to the list of reserved words for SQLite so that
|
||
this word will be quoted when used as a label or column
|
||
name. Pull request courtesy Thodoris Sotiropoulos. References:
|
||
#5395
|
||
* mssql
|
||
+ Refined the logic used by the SQL Server dialect to interpret
|
||
multi-part schema names that contain many dots, to not actually
|
||
lose any dots if the name does not have bracking or quoting
|
||
used, and additionally to support a “dbname” token that has many
|
||
parts including that it may have multiple,
|
||
independently-bracketed sections. References: #5364, #5366
|
||
+ Fixed an issue in the pyodbc connector such that a warning about
|
||
pyodbc “drivername” would be emitted when using a totally empty
|
||
URL. Empty URLs are normal when producing a non-connected
|
||
dialect object or when using the “creator” argument to
|
||
create_engine(). The warning now only emits if the driver name
|
||
is missing but other parameters are still present. References:
|
||
#5346
|
||
+ Fixed issue with assembling the ODBC connection string for the
|
||
pyodbc DBAPI. Tokens containing semicolons and/or braces “{}”
|
||
were not being correctly escaped, causing the ODBC driver to
|
||
misinterpret the connection string attributes. References:
|
||
#5373
|
||
+ Fixed issue where datetime.time parameters were being converted
|
||
to datetime.datetime, making them incompatible with comparisons
|
||
like >= against an actual TIME column. References: #5339
|
||
+ Fixed an issue where the is_disconnect function in the SQL
|
||
Server pyodbc dialect was incorrectly reporting the disconnect
|
||
state when the exception messsage had a substring that matched a
|
||
SQL Server ODBC error code. References: #5359
|
||
+ Moved the supports_sane_rowcount_returning = False requirement
|
||
from the PyODBCConnector level to the MSDialect_pyodbc since
|
||
pyodbc does work properly in some circumstances. References:
|
||
#5321
|
||
* oracle
|
||
+ Fixed bug in Oracle dialect where indexes that contain the full
|
||
set of primary key columns would be mistaken as the primary key
|
||
index itself, which is omitted, even if there were
|
||
multiples. The check has been refined to compare the name of the
|
||
primary key constraint against the index name itself, rather
|
||
than trying to guess based on the columns present in the index.
|
||
References: #5421
|
||
* misc
|
||
+ Added new option --raw to the examples.performance suite which
|
||
will dump the raw profile test for consumption by any number of
|
||
profiling visualizer tools. Removed the “runsnake” option as
|
||
runsnake is very hard to build at this point;
|
||
|
||
-------------------------------------------------------------------
|
||
Sat May 23 19:53:51 UTC 2020 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.3.17:
|
||
* orm
|
||
+ Added an accessor Comparator.expressions which provides access
|
||
to the group of columns mapped under a multi-column
|
||
ColumnProperty attribute. References: #5262
|
||
+ Introduce relationship.sync_backref flag in a relationship to
|
||
control if the synchronization events that mutate the in-Python
|
||
attributes are added. This supersedes the previous change #5149,
|
||
which warned that viewonly=True relationship target of a
|
||
back_populates or backref configuration would be disallowed.
|
||
References: #5237
|
||
+ Fixed bug where using with_polymorphic() as the target of a join
|
||
via RelationshipComparator.of_type() on a mapper that already
|
||
has a subquery-based with_polymorphic setting that’s equivalent
|
||
to the one requested would not correctly alias the ON clause in
|
||
the join. References: #5288
|
||
+ Fixed issue in the area of where loader options such as
|
||
selectinload() interact with the baked query system, such that
|
||
the caching of a query is not supposed to occur if the loader
|
||
options themselves have elements such as with_polymorphic()
|
||
objects in them that currently are not cache-compatible. The
|
||
baked loader could sometimes not fully invalidate itself in
|
||
these some of these scenarios leading to missed eager loads.
|
||
References: #5303
|
||
+ Modified the internal “identity set” implementation, which is a
|
||
set that hashes objects on their id() rather than their hash
|
||
values, to not actually call the __hash__() method of the
|
||
objects, which are typically user-mapped objects. Some methods
|
||
were calling this method as a side effect of the implementation.
|
||
References: #5304
|
||
+ An informative error message is raised when an ORM many-to-one
|
||
comparison is attempted against an object that is not an actual
|
||
mapped instance. Comparisons such as those to scalar subqueries
|
||
aren’t supported; generalized comparison with subqueries is
|
||
better achieved using Comparator.has(). References: #5269
|
||
* engine
|
||
+ Fixed fairly critical issue where the DBAPI connection could be
|
||
returned to the connection pool while still in an un-rolled-back
|
||
state. The reset agent responsible for rolling back the
|
||
connection could be corrupted in the case that the transaction
|
||
was “closed” without being rolled back or committed, which can
|
||
occur in some scenarios when using ORM sessions and emitting
|
||
.close() in a certain pattern involving savepoints. The fix
|
||
ensures that the reset agent is always active. References:
|
||
#5326
|
||
* schema
|
||
+ Fixed issue where an Index that is deferred in being associated
|
||
with a table, such as as when it contains a Column that is not
|
||
associated with any Table yet, would fail to attach correctly if
|
||
it also contained a non table-oriented expession. References:
|
||
#5298
|
||
+ A warning is emitted when making use of the
|
||
MetaData.sorted_tables attribute as well as the sort_tables()
|
||
function, and the given tables cannot be correctly sorted due to
|
||
a cyclic dependency between foreign key constraints. In this
|
||
case, the functions will no longer sort the involved tables by
|
||
foreign key, and a warning will be emitted. Other tables that
|
||
are not part of the cycle will still be returned in dependency
|
||
order. Previously, the sorted_table routines would return a
|
||
collection that would unconditionally omit all foreign keys when
|
||
a cycle was detected, and no warning was emitted. References:
|
||
#5316
|
||
+ Add comment attribute to Column __repr__ method. References:
|
||
#4138
|
||
* postgresql
|
||
+ Added support for columns or type ARRAY of Enum, JSON or JSONB
|
||
in PostgreSQL. Previously a workaround was required in these use
|
||
cases. References: #5265
|
||
+ Raise an explicit CompileError when adding a table with a column
|
||
of type ARRAY of Enum configured with Enum.native_enum set to
|
||
False when Enum.create_constraint is not set to False
|
||
References: #5266
|
||
* mssql
|
||
+ Fix a regression introduced by the reflection of computed column
|
||
in MSSQL when using the legacy TDS version 4.2. The dialect will
|
||
try to detect the protocol version of first connect and run in
|
||
compatibility mode if it cannot detect it. References: #5255
|
||
+ Fix a regression introduced by the reflection of computed column
|
||
in MSSQL when using SQL server versions before 2012, which does
|
||
not support the concat function. References: #5271
|
||
* oracle
|
||
+ Some modifications to how the cx_oracle dialect sets up
|
||
per-column outputtype handlers for LOB and numeric datatypes to
|
||
adjust for potential changes coming in cx_Oracle 8. References:
|
||
#5246
|
||
+ Changed the implementation of fetching CLOB and BLOB objects to
|
||
use cx_Oracle’s native implementation which fetches CLOB/BLOB
|
||
objects inline with other result columns, rather than performing
|
||
a separate fetch. As always, this can be disabled by setting
|
||
auto_convert_lobs to False.
|
||
+ As part of this change, the behavior of a CLOB that was given a
|
||
blank string on INSERT now returns None on SELECT, which is now
|
||
consistent with that of VARCHAR on Oracle. References: #5314
|
||
* firebird
|
||
+ Adjusted dialect loading for firebird:// URIs so the external
|
||
sqlalchemy-firebird dialect will be used if it has been
|
||
installed, otherwise fall back to the (now deprecated) internal
|
||
Firebird dialect. References: #5278
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Apr 9 16:23:41 UTC 2020 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.3.16:
|
||
* orm
|
||
+ Fixed bug in orm.selectinload() loading option where two or more
|
||
loaders that represent different relationships with the same
|
||
string key name as referenced from a single
|
||
orm.with_polymorphic() construct with multiple subclass mappers
|
||
would fail to invoke each subqueryload separately, instead
|
||
making use of a single string-based slot that would prevent the
|
||
other loaders from being invoked. References: #5228
|
||
+ Fixed issue where a lazyload that uses session-local “get”
|
||
against a target many-to-one relationship where an object with
|
||
the correct primary key is present, however it’s an instance of
|
||
a sibling class, does not correctly return None as is the case
|
||
when the lazy loader actually emits a load for that row.
|
||
References: #5210
|
||
+ Modified the queries used by subqueryload and selectinload to no
|
||
longer ORDER BY the primary key of the parent entity; this
|
||
ordering was there to allow the rows as they come in to be
|
||
copied into lists directly with a minimal level of Python-side
|
||
collation. However, these ORDER BY clauses can negatively impact
|
||
the performance of the query as in many scenarios these columns
|
||
are derived from a subquery or are otherwise not actual primary
|
||
key columns such that SQL planners cannot make use of
|
||
indexes. The Python-side collation uses the native
|
||
itertools.group_by() to collate the incoming rows, and has been
|
||
modified to allow multiple row-groups-per-parent to be assembled
|
||
together using list.extend(), which should still allow for
|
||
relatively fast Python-side performance. There will still be an
|
||
ORDER BY present for a relationship that includes an explicit
|
||
order_by parameter, however this is the only ORDER BY that will
|
||
be added to the query for both kinds of loading. References:
|
||
#5162
|
||
* orm declarative
|
||
+ The string argument accepted as the first positional argument by
|
||
the relationship() function when using the Declarative API is no
|
||
longer interpreted using the Python eval() function; instead,
|
||
the name is dot separated and the names are looked up directly
|
||
in the name resolution dictionary without treating the value as
|
||
a Python expression. However, passing a string argument to the
|
||
other relationship() parameters that necessarily must accept
|
||
Python expressions will still use eval(); the documentation has
|
||
been clarified to ensure that there is no ambiguity that this is
|
||
in use. See also Evaluation of relationship arguments - details
|
||
on string evaluation References: #5238
|
||
* sql
|
||
+ Add ability to literal compile a DateTime, Date or :class:”Time”
|
||
when using the string dialect for debugging purposes. This
|
||
change does not impact real dialect implementation that retain
|
||
their current behavior. References: #5052
|
||
* schema
|
||
+ Added support for reflection of “computed” columns, which are
|
||
now returned as part of the structure returned by
|
||
Inspector.get_columns(). When reflecting full Table objects,
|
||
computed columns will be represented using the Computed
|
||
construct. References: #5063
|
||
* postgresql
|
||
+ Fixed issue where a “covering” index, e.g. those which have an
|
||
INCLUDE clause, would be reflected including all the columns in
|
||
INCLUDE clause as regular columns. A warning is now emitted if
|
||
these additional columns are detected indicating that they are
|
||
currently ignored. Note that full support for “covering” indexes
|
||
is part of #4458. Pull request courtesy Marat Sharafutdinov.
|
||
References: #5205
|
||
* mysql
|
||
+ Fixed issue in MySQL dialect when connecting to a psuedo-MySQL
|
||
database such as that provided by ProxySQL, the up front check
|
||
for isolation level when it returns no row will not prevent the
|
||
dialect from continuing to connect. A warning is emitted that
|
||
the isolation level could not be detected. References: #5239
|
||
* sqlite
|
||
+ Implemented AUTOCOMMIT isolation level for SQLite when using
|
||
pysqlite. References: #5164
|
||
* mssql
|
||
+ Added support for ColumnOperators.is_distinct_from() and
|
||
ColumnOperators.isnot_distinct_from() to SQL Server, MySQL, and
|
||
Oracle. References: #5137
|
||
* oracle
|
||
+ Implemented AUTOCOMMIT isolation level for Oracle when using
|
||
cx_Oracle. Also added a fixed default isolation level of READ
|
||
COMMITTED for Oracle. References: #5200
|
||
+ Fixed regression / incorrect fix caused by fix for #5146 where
|
||
the Oracle dialect reads from the “all_tab_comments” view to get
|
||
table comments but fails to accommodate for the current owner of
|
||
the table being requested, causing it to read the wrong comment
|
||
if multiple tables of the same name exist in multiple schemas.
|
||
References: #5146
|
||
* misc
|
||
+ Fixed an issue that prevented the test suite from running with
|
||
the recently released py.test 5.4.0. References: #5201
|
||
+ Enum type now supports the parameter Enum.length to specify the
|
||
length of the VARCHAR column to create when using non native
|
||
enums by setting Enum.native_enum to False References: #5183
|
||
+ Ensured that the “pyproject.toml” file is not included in
|
||
builds, as the presence of this file indicates to pip that a
|
||
pep-517 installation process should be used. As this mode of
|
||
operation appears to be not well supported by current tools /
|
||
distros, these problems are avoided within the scope of
|
||
SQLAlchemy installation by omitting the file. References: #5207
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Mar 14 12:26:48 UTC 2020 - Dirk Mueller <dmueller@suse.com>
|
||
|
||
- update to 1.3.15:
|
||
* Adjusted the error message emitted by :meth:`.Query.join` when a left hand
|
||
side can't be located that the :meth:`.Query.select_from` method is the
|
||
best way to resolve the issue. Also, within the 1.3 series, used a
|
||
deterministic ordering when determining the FROM clause from a given column
|
||
entity passed to :class:`.Query` so that the same expression is determined
|
||
each time.
|
||
* Fixed regression in 1.3.14 due to :ticket:`4849` where a sys.exc_info()
|
||
call failed to be invoked correctly when a flush error would occur. Test
|
||
coverage has been added for this exception case.
|
||
* Fixed bug where a CTE of an INSERT/UPDATE/DELETE that also uses RETURNING
|
||
could then not be SELECTed from directly, as the internal state of the
|
||
compiler would try to treat the outer SELECT as a DELETE statement itself
|
||
and access nonexistent state.
|
||
* Fixed regression caused in 1.3.13 by :ticket:`5056` where a refactor of the
|
||
ORM path registry system made it such that a path could no longer be
|
||
compared to an empty tuple, which can occur in a particular kind of joined
|
||
eager loading path. The "empty tuple" use case has been resolved so that
|
||
the path registry is compared to a path registry in all cases;
|
||
- Fix build for older distributions by buildrequiring a new-enough pytest
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Mar 12 07:37:00 UTC 2020 - Tomáš Chvátal <tchvatal@suse.com>
|
||
|
||
- Fix build without python2
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Jan 26 21:18:31 UTC 2020 - Arun Persaud <arun@gmx.de>
|
||
|
||
- specfile:
|
||
* update copyright year
|
||
|
||
- update to version 1.3.13:
|
||
* orm
|
||
+ Added test support and repaired a wide variety of unnecessary
|
||
reference cycles created for short-lived objects, mostly in the
|
||
area of ORM queries. Thanks much to Carson Ip for the help on
|
||
this. References: #5050, #5056, #5071
|
||
+ Fixed regression in loader options introduced in 1.3.0b3 via
|
||
#4468 where the ability to create a loader option using
|
||
PropComparator.of_type() targeting an aliased entity that is an
|
||
inheriting subclass of the entity which the preceding
|
||
relationship refers to would fail to produce a matching
|
||
path. See also #5082 fixed in this same release which involves a
|
||
similar kind of issue. References: #5107
|
||
+ Fixed regression in joined eager loading introduced in 1.3.0b3
|
||
via #4468 where the ability to create a joined option across a
|
||
with_polymorphic() into a polymorphic subclass using
|
||
RelationshipProperty.of_type() and then further along regular
|
||
mapped relationships would fail as the polymorphic subclass
|
||
would not add itself to the load path in a way that could be
|
||
located by the loader strategy. A tweak has been made to resolve
|
||
this scenario. References: #5082
|
||
+ Repaired a warning in the ORM flush process that was not covered
|
||
by test coverage when deleting objects that use the “version_id”
|
||
feature. This warning is generally unreachable unless using a
|
||
dialect that sets the “supports_sane_rowcount” flag to False,
|
||
which is not typically the case however is possible for some
|
||
MySQL configurations as well as older Firebird drivers, and
|
||
likely some third party dialects. References: #5068
|
||
+ Fixed bug where usage of joined eager loading would not properly
|
||
wrap the query inside of a subquery when Query.group_by() were
|
||
used against the query. When any kind of result-limiting
|
||
approach is used, such as DISTINCT, LIMIT, OFFSET, joined eager
|
||
loading embeds the row-limited query inside of a subquery so
|
||
that the collection results are not impacted. For some reason,
|
||
the presence of GROUP BY was never included in this criterion,
|
||
even though it has a similar effect as using
|
||
DISTINCT. Additionally, the bug would prevent using GROUP BY at
|
||
all for a joined eager load query for most database platforms
|
||
which forbid non-aggregated, non-grouped columns from being in
|
||
the query, as the additional columns for the joined eager load
|
||
would not be accepted by the database. References: #5065
|
||
+ Identified a performance issue in the system by which a join is
|
||
constructed based on a mapped relationship. The clause adaption
|
||
system would be used for the majority of join expressions
|
||
including in the common case where no adaptation is needed. The
|
||
conditions under which this adaptation occur have been refined
|
||
so that average non-aliased joins along a simple relationship
|
||
without a “secondary” table use about 70% less function calls.
|
||
* engine
|
||
+ Fixed issue where the collection of value processors on a
|
||
Compiled object would be mutated when “expanding IN” parameters
|
||
were used with a datatype that has bind value processors; in
|
||
particular, this would mean that when using statement caching
|
||
and/or baked queries, the same compiled._bind_processors
|
||
collection would be mutated concurrently. Since these processors
|
||
are the same function for a given bind parameter namespace every
|
||
time, there was no actual negative effect of this issue,
|
||
however, the execution of a Compiled object should never be
|
||
causing any changes in its state, especially given that they are
|
||
intended to be thread-safe and reusable once fully constructed.
|
||
References: #5048
|
||
* sql
|
||
+ A function created using GenericFunction can now specify that
|
||
the name of the function should be rendered with or without
|
||
quotes by assigning the quoted_name construct to the .name
|
||
element of the object. Prior to 1.3.4, quoting was never applied
|
||
to function names, and some quoting was introduced in #4467 but
|
||
no means to force quoting for a mixed case name was
|
||
available. Additionally, the quoted_name construct when used as
|
||
the name will properly register its lowercase name in the
|
||
function registry so that the name continues to be available via
|
||
the func. registry. See also GenericFunction References: #5079
|
||
* postgresql
|
||
+ Added support for prefixes to the CTE construct, to allow
|
||
support for Postgresql 12 “MATERIALIZED” and “NOT MATERIALIZED”
|
||
phrases. Pull request courtesy Marat Sharafutdinov. See also:
|
||
HasCTE.cte() References: #5040
|
||
+ Fixed issue where the PostgreSQL dialect would fail to parse a
|
||
reflected CHECK constraint that was a boolean-valued function
|
||
(as opposed to a boolean-valued expression). References: #5039
|
||
+ Improved detection of two phase transactions requirement for the
|
||
PostgreSQL database by testing that max_prepared_transactions is
|
||
set to a value greater than 0. Pull request courtesy Federico
|
||
Caselli. References: #5057
|
||
* mssql
|
||
+ Fixed issue where a timezone-aware datetime value being
|
||
converted to string for use as a parameter value of a
|
||
mssql.DATETIMEOFFSET column was omitting the fractional seconds.
|
||
References: #5045
|
||
* misc
|
||
+ Fixed bug in sqlalchemy.ext.serializer where a unique
|
||
BindParameter object could conflict with itself if it were
|
||
present in the mapping itself, as well as the filter condition
|
||
of the query, as one side would be used against the
|
||
non-deserialized version and the other side would use the
|
||
deserialized version. Logic is added to BindParameter similar to
|
||
its “clone” method which will uniquify the parameter name upon
|
||
deserialize so that it doesn’t conflict with its original.
|
||
References: #5086
|
||
+ Fixed a few test failures which would occur on Windows due to
|
||
SQLite file locking issues, as well as some timing issues in
|
||
connection pool related tests; pull request courtesy Federico
|
||
Caselli. References: #4946
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Dec 20 18:45:14 UTC 2019 - Dirk Mueller <dmueller@suse.com>
|
||
|
||
- update to version 1.3.12:
|
||
* [orm] [bug] Fixed issue involving lazy="raise" strategy where an ORM delete
|
||
of an object would raise for a simple “use-get” style many-to-one relationship
|
||
that had lazy=”raise” configured. This is inconsistent vs. the change
|
||
introduced in 1.3 as part of #4353, where it was established that a history
|
||
operation that does not expect emit SQL should bypass the lazy="raise" check,
|
||
and instead effectively treat it as lazy="raise_on_sql" for this case. The fix
|
||
adjusts the lazy loader strategy to not raise for the case where the lazy load
|
||
was instructed that it should not emit SQL if the object were not present.
|
||
|
||
* [orm] [bug] Fixed regression introduced in 1.3.0 related to the association
|
||
proxy refactor in #4351 that prevented composite() attributes from working in
|
||
terms of an association proxy that references them.
|
||
|
||
* [orm] [bug] Setting persistence-related flags on relationship() while also
|
||
setting viewonly=True will now emit a regular warning, as these flags do not
|
||
make sense for a viewonly=True relationship. In particular, the “cascade”
|
||
settings have their own warning that is generated based on the individual
|
||
values, such as “delete, delete-orphan”, that should not apply to a viewonly
|
||
relationship. Note however that in the case of “cascade”, these settings are
|
||
still erroneously taking effect even though the relationship is set up as
|
||
“viewonly”. In 1.4, all persistence-related cascade settings will be disallowed
|
||
on a viewonly=True relationship in order to resolve this issue.
|
||
|
||
* [orm] [bug] [py3k] Fixed issue where when assigning a collection to itself
|
||
as a slice, the mutation operation would fail as it would first erase the
|
||
assigned collection inadvertently. As an assignment that does not change the
|
||
contents should not generate events, the operation is now a no-op. Note that
|
||
the fix only applies to Python 3; in Python 2, the __setitem__ hook isn’t
|
||
called in this case; __setslice__ is used instead which recreates the list
|
||
item-by-item in all cases.
|
||
|
||
* [orm] [bug] Fixed issue where by if the “begin” of a transaction failed at
|
||
the Core engine/connection level, such as due to network error or database is
|
||
locked for some transactional recipes, within the context of the Session
|
||
procuring that connection from the conneciton pool and then immediately
|
||
returning it, the ORM Session would not close the connection despite this
|
||
connection not being stored within the state of that Session. This would lead
|
||
to the connection being cleaned out by the connection pool weakref handler
|
||
within garbage collection which is an unpreferred codepath that in some special
|
||
configurations can emit errors in standard error.
|
||
|
||
* sql [sql] [bug] Fixed bug where “distinct” keyword passed to select() would
|
||
not treat a string value as a “label reference” in the same way that the
|
||
select.distinct() does; it would instead raise unconditionally. This keyword
|
||
argument and the others passed to select() will ultimately be deprecated for
|
||
SQLAlchemy 2.0.
|
||
|
||
* [sql] [bug] Changed the text of the exception for “Can’t resolve label
|
||
reference” to include other kinds of label coercions, namely that “DISTINCT” is
|
||
also in this category under the PostgreSQL dialect.
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Nov 16 16:33:38 UTC 2019 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.3.11:
|
||
* orm
|
||
+ [orm] [bug] The relationship.omit_join flag was not intended to
|
||
be manually set to True, and will now emit a warning when this
|
||
occurs. The omit_join optimization is detected automatically,
|
||
and the omit_join flag was only intended to disable the
|
||
optimization in the hypothetical case that the optimization may
|
||
have interfered with correct results, which has not been
|
||
observed with the modern version of this feature. Setting the
|
||
flag to True when it is not automatically detected may cause the
|
||
selectin load feature to not work correctly when a non-default
|
||
primary join condition is in use. References: #4954
|
||
+ [orm] [bug] A warning is emitted if a primary key value is
|
||
passed to Query.get() that consists of None for all primary key
|
||
column positions. Previously, passing a single None outside of a
|
||
tuple would raise a TypeError and passing a composite None
|
||
(tuple of None values) would silently pass through. The fix now
|
||
coerces the single None into a tuple where it is handled
|
||
consistently with the other None conditions. Thanks to Lev
|
||
Izraelit for the help with this. References: #4915
|
||
+ [orm] [bug] The BakedQuery will not cache a query that was
|
||
modified by a QueryEvents.before_compile() event, so that
|
||
compilation hooks that may be applying ad-hoc modifications to
|
||
queries will take effect on each run. In particular this is
|
||
helpful for events that modify queries used in lazy loading as
|
||
well as eager loading such as “select in” loading. In order to
|
||
re-enable caching for a query modified by this event, a new flag
|
||
bake_ok is added; see Using the before_compile event for
|
||
details. A longer term plan to provide a new form of SQL
|
||
caching should solve this kind of issue more comprehensively.
|
||
References: #4947
|
||
+ [orm] [bug] Fixed ORM bug where a “secondary” table that
|
||
referred to a selectable which in some way would refer to the
|
||
local primary table would apply aliasing to both sides of the
|
||
join condition when a relationship-related join, either via
|
||
Query.join() or by joinedload(), were generated. The “local”
|
||
side is now excluded. References: #4974
|
||
+ [orm] [usecase] Added accessor Query.is_single_entity() to
|
||
Query, which will indicate if the results returned by this Query
|
||
will be a list of ORM entities, or a tuple of entities or column
|
||
expressions. SQLAlchemy hopes to improve upon the behavior of
|
||
single entity / tuples in future releases such that the behavior
|
||
would be explicit up front, however this attribute should be
|
||
helpful with the current behavior. Pull request courtesy Patrick
|
||
Hayes. References: #4934
|
||
* engine
|
||
+ [engine] [bug] Fixed bug where parameter repr as used in logging
|
||
and error reporting needs additional context in order to
|
||
distinguish between a list of parameters for a single statement
|
||
and a list of parameter lists, as the “list of lists” structure
|
||
could also indicate a single parameter list where the first
|
||
parameter itself is a list, such as for an array parameter. The
|
||
engine/connection now passes in an additional boolean indicating
|
||
how the parameters should be considered. The only SQLAlchemy
|
||
backend that expects arrays as parameters is that of psycopg2
|
||
which uses pyformat parameters, so this issue has not been too
|
||
apparent, however as other drivers that use positional gain more
|
||
features it is important that this be supported. It also
|
||
eliminates the need for the parameter repr function to guess
|
||
based on the parameter structure passed. References: #4902
|
||
+ [engine] [bug] [postgresql] Fixed bug in Inspector where the
|
||
cache key generation did not take into account arguments passed
|
||
in the form of tuples, such as the tuple of view name styles to
|
||
return for the PostgreSQL dialect. This would lead the inspector
|
||
to cache too generally for a more specific set of criteria. The
|
||
logic has been adjusted to include every keyword element in the
|
||
cache, as every argument is expected to be appropriate for a
|
||
cache else the caching decorator should be bypassed by the
|
||
dialect. References: #4955
|
||
* sql
|
||
+ [sql] [bug] [py3k] Changed the repr() of the quoted_name
|
||
construct to use regular string repr() under Python 3, rather
|
||
than running it through “backslashreplace” escaping, which can
|
||
be misleading. References: #4931
|
||
+ [sql] [usecase] Added new accessors to expressions of type JSON
|
||
to allow for specific datatype access and comparison, covering
|
||
strings, integers, numeric, boolean elements. This revises the
|
||
documented approach of CASTing to string when comparing values,
|
||
instead adding specific functionality into the PostgreSQL,
|
||
SQlite, MySQL dialects to reliably deliver these basic types in
|
||
all cases. See also: JSON, JSON.Comparator.as_string(),
|
||
JSON.Comparator.as_boolean(), JSON.Comparator.as_float(),
|
||
JSON.Comparator.as_integer(), References: #4276
|
||
+ [sql] [usecase] The text() construct now supports “unique” bound
|
||
parameters, which will dynamically uniquify themselves on
|
||
compilation thus allowing multiple text() constructs with the
|
||
same bound parameter names to be combined together. References:
|
||
#4933
|
||
* schema
|
||
+ [schema] [bug] Fixed bug where a table that would have a column
|
||
label overlap with a plain column name, such as “foo.id AS
|
||
foo_id” vs. “foo.foo_id”, would prematurely generate the ._label
|
||
attribute for a column before this overlap could be detected due
|
||
to the use of the index=True or unique=True flag on the column
|
||
in conjunction with the default naming convention of
|
||
"column_0_label". This would then lead to failures when ._label
|
||
were used later to generate a bound parameter name, in
|
||
particular those used by the ORM when generating the WHERE
|
||
clause for an UPDATE statement. The issue has been fixed by
|
||
using an alternate ._label accessor for DDL generation that does
|
||
not affect the state of the Column. The accessor also bypasses
|
||
the key-deduplication step as it is not necessary for DDL, the
|
||
naming is now consistently "<tablename>_<columnname>" without
|
||
any subsequent numeric symbols when used in DDL. References:
|
||
#4911
|
||
+ [schema] [usecase] Added DDL support for “computed columns”;
|
||
these are DDL column specifications for columns that have a
|
||
server-computed value, either upon SELECT (known as “virtual”)
|
||
or at the point of which they are INSERTed or UPDATEd (known as
|
||
“stored”). Support is established for Postgresql, MySQL, Oracle
|
||
SQL Server and Firebird. Thanks to Federico Caselli for lots of
|
||
work on this one. See also: Computed (GENERATED ALWAYS AS)
|
||
Columns References: #4894
|
||
* mysql
|
||
+ [mysql] [bug] Added “Connection was killed” message interpreted
|
||
from the base pymysql.Error class in order to detect closed
|
||
connection, based on reports that this message is arriving via a
|
||
pymysql.InternalError() object which indicates pymysql is not
|
||
handling it correctly. References: #4945
|
||
* mssql
|
||
+ [mssql] [bug] Fixed issue in MSSQL dialect where an
|
||
expression-based OFFSET value in a SELECT would be rejected,
|
||
even though the dialect can render this expression inside of a
|
||
ROW NUMBER-oriented LIMIT/OFFSET construct. References: #4973
|
||
+ [mssql] [bug] Fixed an issue in the Engine.table_names() method
|
||
where it would feed the dialect’s default schema name back into
|
||
the dialect level table function, which in the case of SQL
|
||
Server would interpret it as a dot-tokenized schema name as
|
||
viewed by the mssql dialect, which would cause the method to
|
||
fail in the case where the database username actually had a dot
|
||
inside of it. In 1.3, this method is still used by the
|
||
MetaData.reflect() function so is a prominent codepath. In 1.4,
|
||
which is the current master development branch, this issue
|
||
doesn’t exist, both because MetaData.reflect() isn’t using this
|
||
method nor does the method pass the default schema name
|
||
explicitly. The fix nonetheless guards against the default
|
||
server name value returned by the dialect from being interpreted
|
||
as dot-tokenized name under any circumstances by wrapping it in
|
||
quoted_name(). References: #4923
|
||
* oracle
|
||
+ [oracle] [bug] [firebird] Modified the approach of “name
|
||
normalization” for the Oracle and Firebird dialects, which
|
||
converts from the UPPERCASE-as-case-insensitive convention of
|
||
these dialects into lowercase-as-case-insensitive for
|
||
SQLAlchemy, to not automatically apply the quoted_name construct
|
||
to a name that matches itself under upper or lower case
|
||
conversion, as is the case for many non-european characters. All
|
||
names used within metadata structures are converted to
|
||
quoted_name objects in any case; the change here would only
|
||
affect the output of some inspection functions. References:
|
||
#4931
|
||
+ [oracle] [bug] The sqltypes.NCHAR datatype will now bind to the
|
||
cx_Oracle.FIXED_NCHAR DBAPI data bindings when used in a bound
|
||
parameter, which supplies proper comparison behavior against a
|
||
variable-length string. Previously, the sqltypes.NCHAR datatype
|
||
would bind to cx_oracle.NCHAR which is not fixed length; the
|
||
sqltypes.CHAR datatype already binds to cx_Oracle.FIXED_CHAR so
|
||
it is now consistent that sqltypes.NCHAR binds to
|
||
cx_Oracle.FIXED_NCHAR. References: #4913
|
||
+ [oracle] [usecase] Added dialect-level flag encoding_errors to
|
||
the cx_Oracle dialect, which can be specified as part of
|
||
create_engine(). This is passed to SQLAlchemy’s unicode decoding
|
||
converter under Python 2, and to cx_Oracle’s cursor.var() object
|
||
as the encodingErrors parameter under Python 3, for the very
|
||
unusual case that broken encodings are present in the target
|
||
database which cannot be fetched unless error handling is
|
||
relaxed. The value is ultimately one of the Python “encoding
|
||
errors” parameters passed to decode(). References: #4799
|
||
* firebird
|
||
+ [firebird] [bug] Added additional “disconnect” message “Error
|
||
writing data to the connection” to Firebird disconnection
|
||
detection. Pull request courtesy lukens. References: #4903
|
||
* misc
|
||
+ [bug] [tests] Fixed test failures which would occur with newer
|
||
SQLite as of version 3.30 or greater, due to their addition of
|
||
nulls ordering syntax as well as new restrictions on aggregate
|
||
functions. Pull request courtesy Nils Philippsen. References:
|
||
#4920
|
||
+ [bug] [installation] [windows] Added a workaround for a
|
||
setuptools-related failure that has been observed as occurring
|
||
on Windows installations, where setuptools is not correctly
|
||
reporting a build error when the MSVC build dependencies are not
|
||
installed and therefore not allowing graceful degradation into
|
||
non C extensions builds. References: #4967
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Nov 14 15:17:51 UTC 2019 - Tomáš Chvátal <tchvatal@suse.com>
|
||
|
||
- This package needs full fledged python on runtime so make sure
|
||
we require it
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Oct 30 13:03:18 UTC 2019 - Tomáš Chvátal <tchvatal@suse.com>
|
||
|
||
- Update to 1.3.10:
|
||
* Fixed regression in selectinload loader strategy
|
||
* Passing a plain string expression to Session.query() is deprecated
|
||
* A warning is emitted for a condition in which the Session may
|
||
implicitly swap an object out of the identity map for another one
|
||
with the same primary key
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Aug 31 04:34:30 UTC 2019 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.3.8:
|
||
* orm
|
||
+ Fixed bug where Load objects were not pickleable due to
|
||
mapper/relationship state in the internal context
|
||
dictionary. These objects are now converted to picklable using
|
||
similar techniques as that of other elements within the loader
|
||
option system that have long been serializable. References:
|
||
#4823
|
||
+ Added support for the use of an Enum datatype using Python
|
||
pep-435 enumeration objects as values for use as a primary key
|
||
column mapped by the ORM. As these values are not inherently
|
||
sortable, as required by the ORM for primary keys, a new
|
||
TypeEngine.sort_key_function attribute is added to the typing
|
||
system which allows any SQL type to implement a sorting for
|
||
Python objects of its type which is consulted by the unit of
|
||
work. The Enum type then defines this using the database value
|
||
of a given enumeration. The sorting scheme can be also be
|
||
redefined by passing a callable to the Enum.sort_key_function
|
||
parameter. Pull request courtesy Nicolas Caniart. References:
|
||
#4285
|
||
* engine
|
||
+ Added new parameter create_engine.hide_parameters which when set
|
||
to True will cause SQL parameters to no longer be logged, nor
|
||
rendered in the string representation of a StatementError
|
||
object. References: #4815
|
||
+ Fixed an issue whereby if the dialect “initialize” process which
|
||
occurs on first connect would encounter an unexpected exception,
|
||
the initialize process would fail to complete and then no longer
|
||
attempt on subsequent connection attempts, leaving the dialect
|
||
in an un-initialized, or partially initialized state, within the
|
||
scope of parameters that need to be established based on
|
||
inspection of a live connection. The “invoke once” logic in the
|
||
event system has been reworked to accommodate for this
|
||
occurrence using new, private API features that establish an
|
||
“exec once” hook that will continue to allow the initializer to
|
||
fire off on subsequent connections, until it completes without
|
||
raising an exception. This does not impact the behavior of the
|
||
existing once=True flag within the event system. References:
|
||
#4807
|
||
* postgresql
|
||
+ Revised the approach for the just added support for the psycopg2
|
||
“execute_values()” feature added in 1.3.7 for #4623. The
|
||
approach relied upon a regular expression that would fail to
|
||
match for a more complex INSERT statement such as one which had
|
||
subqueries involved. The new approach matches exactly the string
|
||
that was rendered as the VALUES clause. References: #4623
|
||
+ Fixed bug where Postgresql operators such as
|
||
postgresql.ARRAY.Comparator.contains() and
|
||
postgresql.ARRAY.Comparator.contained_by() would fail to
|
||
function correctly for non-integer values when used against a
|
||
postgresql.array object, due to an erroneous assert statement.
|
||
References: #4822
|
||
+ Added support for reflection of CHECK constraints that include
|
||
the special PostgreSQL qualifier “NOT VALID”, which can be
|
||
present for CHECK constraints that were added to an exsiting
|
||
table with the directive that they not be applied to existing
|
||
data in the table. The PostgreSQL dictionary for CHECK
|
||
constraints as returned by Inspector.get_check_constraints() may
|
||
include an additional entry dialect_options which within will
|
||
contain an entry "not_valid": True if this symbol is
|
||
detected. Pull request courtesy Bill Finn. References: #4824
|
||
* sqlite
|
||
+ Fixed bug where a FOREIGN KEY that was set up to refer to the
|
||
parent table by table name only without the column names would
|
||
not correctly be reflected as far as setting up the “referred
|
||
columns”, since SQLite’s PRAGMA does not report on these columns
|
||
if they weren’t given explicitly. For some reason this was
|
||
harcoded to assume the name of the local column, which might
|
||
work for some cases but is not correct. The new approach
|
||
reflects the primary key of the referred table and uses the
|
||
constraint columns list as the referred columns list, if the
|
||
remote column(s) aren’t present in the reflected pragma
|
||
directly. References: #4810
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Aug 25 17:59:04 UTC 2019 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.3.7:
|
||
* orm
|
||
+ Fixed regression caused by new selectinload for many-to-one
|
||
logic where a primaryjoin condition not based on real foreign
|
||
keys would cause KeyError if a related object did not exist for
|
||
a given key value on the parent object. References: #4777
|
||
+ Fixed bug where using Query.first() or a slice expression in
|
||
conjunction with a query that has an expression based “offset”
|
||
applied would raise TypeError, due to an “or” conditional
|
||
against “offset” that did not expect it to be a SQL expression
|
||
as opposed to an integer or None. References: #4803
|
||
* sql
|
||
+ Fixed issue where Index object which contained a mixture of
|
||
functional expressions which were not resolvable to a particular
|
||
column, in combination with string-based column names, would
|
||
fail to initialize its internal state correctly leading to
|
||
failures during DDL compilation. References: #4778
|
||
+ Fixed bug where TypeEngine.column_expression() method would not
|
||
be applied to subsequent SELECT statements inside of a UNION or
|
||
other CompoundSelect, even though the SELECT statements are
|
||
rendered at the topmost level of the statement. New logic now
|
||
differentiates between rendering the column expression, which is
|
||
needed for all SELECTs in the list, vs. gathering the returned
|
||
data type for the result row, which is needed only for the first
|
||
SELECT. References: #4787
|
||
+ Fixed issue where internal cloning of SELECT constructs could
|
||
lead to a key error if the copy of the SELECT changed its state
|
||
such that its list of columns changed. This was observed to be
|
||
occurring in some ORM scenarios which may be unique to 1.3 and
|
||
above, so is partially a regression fix. References: #4780
|
||
* postgresql
|
||
+ Added new dialect flag for the psycopg2 dialect,
|
||
executemany_mode which supersedes the previous experimental
|
||
use_batch_mode flag. executemany_mode supports both the “execute
|
||
batch” and “execute values” functions provided by psycopg2, the
|
||
latter which is used for compiled insert() constructs. Pull
|
||
request courtesy Yuval Dinari. See also: Psycopg2 Fast
|
||
Execution Helpers; References: #4623
|
||
* mysql
|
||
+ The MySQL dialects will emit “SET NAMES” at the start of a
|
||
connection when charset is given to the MySQL driver, to appease
|
||
an apparent behavior observed in MySQL 8.0 that raises a
|
||
collation error when a UNION includes string columns unioned
|
||
against columns of the form CAST(NULL AS CHAR(..)), which is
|
||
what SQLAlchemy’s polymorphic_union function does. The issue
|
||
seems to have affected PyMySQL for at least a year, however has
|
||
recently appeared as of mysqlclient 1.4.4 based on changes in
|
||
how this DBAPI creates a connection. As the presence of this
|
||
directive impacts three separate MySQL charset settings which
|
||
each have intricate effects based on their presense, SQLAlchemy
|
||
will now emit the directive on new connections to ensure correct
|
||
behavior. References: #4804
|
||
+ Added another fix for an upstream MySQL 8 issue where a case
|
||
sensitive table name is reported incorrectly in foreign key
|
||
constraint reflection, this is an extension of the fix first
|
||
added for #4344 which affects a case sensitive column name. The
|
||
new issue occurs through MySQL 8.0.17, so the general logic of
|
||
the 88718 fix remains in place. See also:
|
||
https://bugs.mysql.com/bug.php?id=96365 - upstream bug;
|
||
References: #4751
|
||
+ Added reserved words ARRAY and MEMBER to the MySQL reserved
|
||
words list, as MySQL 8.0 has now made these reserved.
|
||
References: #4783
|
||
* sqlite
|
||
+ The dialects that support json are supposed to take arguments
|
||
json_serializer and json_deserializer at the create_engine()
|
||
level, however the SQLite dialect calls them _json_serilizer and
|
||
_json_deserilalizer. The names have been corrected, the old
|
||
names are accepted with a change warning, and these parameters
|
||
are now documented as create_engine.json_serializer and
|
||
create_engine.json_deserializer. References: #4798
|
||
+ Fixed bug where usage of “PRAGMA table_info” in SQLite dialect
|
||
meant that reflection features to detect for table existence,
|
||
list of table columns, and list of foreign keys, would default
|
||
to any table in any attached database, when no schema name was
|
||
given and the table did not exist in the base schema. The fix
|
||
explicitly runs PRAGMA for the ‘main’ schema and then the ‘temp’
|
||
schema if the ‘main’ returned no rows, to maintain the behavior
|
||
of tables + temp tables in the “no schema” namespace, attached
|
||
tables only in the “schema” namespace. References: #4793
|
||
* mssql
|
||
+ Added new mssql.try_cast() construct for SQL Server which emits
|
||
“TRY_CAST” syntax. Pull request courtesy Leonel Atencio.
|
||
References: #4782
|
||
* misc
|
||
+ Fixed issue in event system where using the once=True flag with
|
||
dynamically generated listener functions would cause event
|
||
registration of future events to fail if those listener
|
||
functions were garbage collected after they were used, due to an
|
||
assumption that a listened function is strongly referenced. The
|
||
“once” wrapped is now modified to strongly reference the inner
|
||
function persistently, and documentation is updated that using
|
||
“once” does not imply automatic de-registration of listener
|
||
functions. References: #4794
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Jul 22 16:08:19 UTC 2019 - Todd R <toddrme2178@gmail.com>
|
||
|
||
- update to version 1.3.6
|
||
+ orm
|
||
* [feature] Added new loader option method Load.options()
|
||
which allows loader options to be constructed hierarchically,
|
||
so that many sub-options can be applied to a particular path
|
||
without needing to call defaultload() many times.
|
||
* [bug] Fixed regression caused by #4365 where a join from an
|
||
entity to itself without using aliases no longer raises an
|
||
informative error message, instead failing on an assertion.
|
||
The informative error condition has been restored.
|
||
* [bug] Fixed an issue where the orm._ORMJoin.join() method,
|
||
which is a not-internally-used ORM-level method that exposes
|
||
what is normally an internal process of Query.join(), did
|
||
not propagate the full and outerjoin keyword arguments
|
||
correctly.
|
||
* [bug] Fixed bug where a many-to-one relationship that
|
||
specified uselist=True would fail to update correctly during
|
||
a primary key change where a related column needs to change.
|
||
* [bug] Fixed bug where the detection for many-to-one or
|
||
one-to-one use with a “dynamic” relationship, which is an
|
||
invalid configuration, would fail to raise if the
|
||
relationship were configured with uselist=True. The current
|
||
fix is that it warns, instead of raises, as this would
|
||
otherwise be backwards incompatible, however in a future
|
||
release it will be a raise.
|
||
* [bug] Fixed bug where a synonym created against a mapped
|
||
attribute that does not exist yet, as is the case when it
|
||
refers to backref before mappers are configured, would raise
|
||
recursion errors when trying to test for attributes on it
|
||
which ultimately don’t exist (as occurs when the classes are
|
||
run through Sphinx autodoc), as the unconfigured state of
|
||
the synonym would put it into an attribute not found loop.
|
||
* [performance] The optimzation applied to selectin loading
|
||
in #4340 where a JOIN is not needed to eagerly load related
|
||
items is now applied to many-to-one relationships as well,
|
||
so that only the related table is queried for a simple join
|
||
condition. In this case, the related items are queried based
|
||
on the value of a foreign key column on the parent; if these
|
||
columns are deferred or otherwise not loaded on any of the
|
||
parent objects in the collection, the loader falls back to the
|
||
JOIN method.
|
||
+ engine
|
||
* [bug] Fixed bug where using reflection function such as
|
||
MetaData.reflect() with an Engine object that had execution
|
||
options applied to it would fail, as the resulting
|
||
OptionEngine proxy object failed to include a .engine
|
||
attribute used within the reflection routines.
|
||
+ sql
|
||
* [bug] Adjusted the initialization for Enum to minimize how
|
||
often it invokes the .__members__ attribute of a given
|
||
PEP-435 enumeration object, to suit the case where this
|
||
attribute is expensive to invoke, as is the case for some
|
||
popular third party enumeration libraries.
|
||
* [bug] [postgresql] Fixed issue where the array_agg construct
|
||
in combination with FunctionElement.filter() would not
|
||
produce the correct operator precedence in combination
|
||
with the array index operator.
|
||
* [bug] Fixed an unlikely issue where the “corresponding
|
||
column” routine for unions and other CompoundSelect objects
|
||
could return the wrong column in some overlapping column
|
||
situtations, thus potentially impacting some ORM operations
|
||
when set operations are in use, if the underlying select()
|
||
constructs were used previously in other similar kinds of
|
||
routines, due to a cached value not being cleared.
|
||
+ postgresql
|
||
* [usecase] Added support for reflection of indexes on
|
||
PostgreSQL partitioned tables, which was added to PostgreSQL
|
||
as of version 11.
|
||
* [usecase] Added support for multidimensional Postgresql array
|
||
literals via nesting the postgresql.array object within
|
||
another one. The multidimensional array type is detected
|
||
automatically.
|
||
+ mysql
|
||
* [bug] Fixed bug where the special logic to render “NULL” for
|
||
the TIMESTAMP datatype when nullable=True would not work if the
|
||
column’s datatype were a TypeDecorator or a Variant. The logic
|
||
now ensures that it unwraps down to the original TIMESTAMP so
|
||
that this special case NULL keyword is correctly rendered when
|
||
requested.
|
||
* [bug] Enhanced MySQL/MariaDB version string parsing to
|
||
accommodate for exotic MariaDB version strings where the
|
||
“MariaDB” word is embedded among other alphanumeric
|
||
characters such as “MariaDBV1”. This detection is critical
|
||
in order to correctly accommodate for API features that have
|
||
split between MySQL and MariaDB such as the
|
||
“transaction_isolation” system variable.
|
||
+ sqlite
|
||
* [usecase] Added support for composite (tuple) IN operators
|
||
with SQLite, by rendering the VALUES keyword for this backend.
|
||
As other backends such as DB2 are known to use the same syntax,
|
||
the syntax is enabled in the base compiler using a dialect-level
|
||
flag tuple_in_values. The change also includes support for
|
||
“empty IN tuple” expressions for SQLite when using “in_()”
|
||
between a tuple value and an empty set.
|
||
+ mssql
|
||
* [bug] Ensured that the queries used to reflect indexes and
|
||
view definitions will explicitly CAST string parameters into
|
||
NVARCHAR, as many SQL Server drivers frequently treat string
|
||
values, particularly those with non-ascii characters or
|
||
larger string values, as TEXT which often don’t compare
|
||
correctly against VARCHAR characters in SQL Server’s
|
||
information schema tables for some reason. These CAST
|
||
operations already take place for reflection queries against
|
||
SQL Server information_schema. tables but were missing from
|
||
three additional queries that are against sys.tables.
|
||
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Jun 24 00:25:53 UTC 2019 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.3.5:
|
||
* orm
|
||
+ Fixed a series of related bugs regarding joined table
|
||
inheritance more than two levels deep, in conjunction with
|
||
modification to primary key values, where those primary key
|
||
columns are also linked together in a foreign key relationship
|
||
as is typical for joined table inheritance. The intermediary
|
||
table in a three-level inheritance hierachy will now get its
|
||
UPDATE if only the primary key value has changed and
|
||
passive_updates=False (e.g. foreign key constraints not being
|
||
enforced), whereas before it would be skipped; similarly, with
|
||
passive_updates=True (e.g. ON UPDATE CASCADE in effect), the
|
||
third-level table will not receive an UPDATE statement as was
|
||
the case earlier which would fail since CASCADE already modified
|
||
it. In a related issue, a relationship linked to a three-level
|
||
inheritance hierarchy on the primary key of an intermediary
|
||
table of a joined-inheritance hierarchy will also correctly have
|
||
its foreign key column updated when the parent object’s primary
|
||
key is modified, even if that parent object is a subclass of the
|
||
linked parent class, whereas before these classes would not be
|
||
counted. References: #4723
|
||
+ Fixed bug where the Mapper.all_orm_descriptors accessor would
|
||
return an entry for the Mapper itself under the declarative
|
||
__mapper___ key, when this is not a descriptor. The
|
||
.is_attribute flag that’s present on all InspectionAttr objects
|
||
is now consulted, which has also been modified to be True for an
|
||
association proxy, as it was erroneously set to False for this
|
||
object. References: #4729
|
||
+ Fixed regression in Query.join() where the aliased=True flag
|
||
would not properly apply clause adaptation to filter criteria,
|
||
if a previous join were made to the same entity. This is because
|
||
the adapters were placed in the wrong order. The order has been
|
||
reversed so that the adapter for the most recent aliased=True
|
||
call takes precedence as was the case in 1.2 and earlier. This
|
||
broke the “elementtree” examples among other things.
|
||
References: #4704
|
||
+ Replaced the Python compatbility routines for getfullargspec()
|
||
with a fully vendored version from Python 3.3. Originally,
|
||
Python was emitting deprecation warnings for this function in
|
||
Python 3.8 alphas. While this change was reverted, it was
|
||
observed that Python 3 implementations for getfullargspec() are
|
||
an order of magnitude slower as of the 3.4 series where it was
|
||
rewritten against Signature. While Python plans to improve upon
|
||
this situation, SQLAlchemy projects for now are using a simple
|
||
replacement to avoid any future issues. References: #4674
|
||
+ Reworked the attribute mechanics used by AliasedClass to no
|
||
longer rely upon calling __getattribute__ on the MRO of the
|
||
wrapped class, and to instead resolve the attribute normally on
|
||
the wrapped class using getattr(), and then unwrap/adapt
|
||
that. This allows a greater range of attribute styles on the
|
||
mapped class including special __getattr__() schemes; but it
|
||
also makes the code simpler and more resilient in general.
|
||
References: #4694
|
||
* sql
|
||
+ Fixed a series of quoting issues which all stemmed from the
|
||
concept of the literal_column() construct, which when being
|
||
“proxied” through a subquery to be referred towards by a label
|
||
that matches its text, the label would not have quoting rules
|
||
applied to it, even if the string in the Label were set up as a
|
||
quoted_name construct. Not applying quoting to the text of the
|
||
Label is a bug because this text is strictly a SQL identifier
|
||
name and not a SQL expression, and the string should not have
|
||
quotes embedded into it already unlike the literal_column()
|
||
which it may be applied towards. The existing behavior of a
|
||
non-labeled literal_column() being propagated as is on the
|
||
outside of a subquery is maintained in order to help with manual
|
||
quoting schemes, although it’s not clear if valid SQL can be
|
||
generated for such a construct in any case. References: #4730
|
||
* postgresql
|
||
+ Fixed bug where PostgreSQL dialect could not correctly reflect
|
||
an ENUM datatype that has no members, returning a list with None
|
||
for the get_enums() call and raising a TypeError when reflecting
|
||
a column which has such a datatype. The inspection now returns
|
||
an empty list. References: #4701
|
||
+ Added support for column sorting flags when reflecting indexes
|
||
for PostgreSQL, including ASC, DESC, NULLSFIRST, NULLSLAST. Also
|
||
adds this facility to the reflection system in general which can
|
||
be applied to other dialects in future releases. Pull request
|
||
courtesy Eli Collins. References: #4717
|
||
* mysql
|
||
+ Fixed bug where MySQL ON DUPLICATE KEY UPDATE would not
|
||
accommodate setting a column to the value NULL. Pull request
|
||
courtesy Lukáš Banič. References: #4715
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Jun 8 23:09:01 UTC 2019 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.3.4:
|
||
* orm
|
||
+ Fixed issue where the AttributeEvents.active_history flag would
|
||
not be set for an event listener that propgated to a subclass
|
||
via the AttributeEvents.propagate flag. This bug has been
|
||
present for the full span of the AttributeEvents system.
|
||
References: #4695
|
||
+ Fixed regression where new association proxy system was still
|
||
not proxying hybrid attributes when they made use of the
|
||
@hybrid_property.expression decorator to return an alternate SQL
|
||
expression, or when the hybrid returned an arbitrary
|
||
PropComparator, at the expression level. This involved futher
|
||
generalization of the heuristics used to detect the type of
|
||
object being proxied at the level of QueryableAttribute, to
|
||
better detect if the descriptor ultimately serves mapped classes
|
||
or column expressions. References: #4690
|
||
+ Applied the mapper “configure mutex” against the declarative
|
||
class mapping process, to guard against the race which can occur
|
||
if mappers are used while dynamic module import schemes are
|
||
still in the process of configuring mappers for related
|
||
classes. This does not guard against all possible race
|
||
conditions, such as if the concurrent import has not yet
|
||
encountered the dependent classes as of yet, however it guards
|
||
against as much as possible within the SQLAlchemy declarative
|
||
process. References: #4686
|
||
+ A warning is now emitted for the case where a transient object
|
||
is being merged into the session with Session.merge() when that
|
||
object is already transient in the Session. This warns for the
|
||
case where the object would normally be double-inserted.
|
||
References: #4647
|
||
+ Fixed regression in new relationship m2o comparison logic first
|
||
introduced at Improvement to the behavior of many-to-one query
|
||
expressions when comparing to an attribute that is persisted as
|
||
NULL and is in an un-fetched state in the mapped instance. Since
|
||
the attribute has no explicit default, it needs to default to
|
||
NULL when accessed in a persistent setting. References: #4676
|
||
* engine
|
||
+ Moved the “rollback” which occurs during dialect initialization
|
||
so that it occurs after additional dialect-specific initialize
|
||
steps, in particular those of the psycopg2 dialect which would
|
||
inadvertently leave transactional state on the first new
|
||
connection, which could interfere with some psycopg2-specific
|
||
APIs which require that no transaction is started. Pull request
|
||
courtesy Matthew Wilkes. References: #4663
|
||
* sql
|
||
+ Fixed that the GenericFunction class was inadvertently
|
||
registering itself as one of the named functions. Pull request
|
||
courtesy Adrien Berchet. References: #4653
|
||
+ Fixed issue where double negation of a boolean column wouldn’t
|
||
reset the “NOT” operator. References: #4618
|
||
+ The GenericFunction namespace is being migrated so that function
|
||
names are looked up in a case-insensitive manner, as SQL
|
||
functions do not collide on case sensitive differences nor is
|
||
this something which would occur with user-defined functions or
|
||
stored procedures. Lookups for functions declared with
|
||
GenericFunction now use a case insensitive scheme, however a
|
||
deprecation case is supported which allows two or more
|
||
GenericFunction objects with the same name of different cases to
|
||
exist, which will cause case sensitive lookups to occur for that
|
||
particular name, while emitting a warning at function
|
||
registration time. Thanks to Adrien Berchet for a lot of work on
|
||
this complicated feature. References: #4569
|
||
* postgresql
|
||
+ Fixed an issue where the “number of rows matched” warning would
|
||
emit even if the dialect reported
|
||
“supports_sane_multi_rowcount=False”, as is the case for
|
||
psycogp2 with use_batch_mode=True and others. References: #4661
|
||
* mysql
|
||
+ Added support for DROP CHECK constraint which is required by
|
||
MySQL 8.0.16 to drop a CHECK constraint; MariaDB supports plain
|
||
DROP CONSTRAINT. The logic distinguishes between the two
|
||
syntaxes by checking the server version string for MariaDB
|
||
presence. Alembic migrations has already worked around this
|
||
issue by implementing its own DROP for MySQL / MariaDB CHECK
|
||
constraints, however this change implements it straight in Core
|
||
so that its available for general use. Pull request courtesy
|
||
Hannes Hansen. References: #4650
|
||
* mssql
|
||
+ Added support for SQL Server filtered indexes, via the
|
||
mssql_where parameter which works similarly to that of the
|
||
postgresql_where index function in the PostgreSQL dialect. See
|
||
also: Filtered Indexes References: #4657
|
||
+ Added error code 20047 to “is_disconnect” for pymssql. Pull
|
||
request courtesy Jon Schuff. References: #4680
|
||
* misc
|
||
+ Removed errant “sqla_nose.py” symbol from MANIFEST.in which
|
||
created an undesirable warning message. References: #4625
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Apr 21 22:00:19 UTC 2019 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.3.3:
|
||
* orm
|
||
+ Fixed 1.3 regression in new “ambiguous FROMs” query logic
|
||
introduced in Query.join() handles ambiguity in deciding the
|
||
“left” side more explicitly where a Query that explicitly places
|
||
an entity in the FROM clause with Query.select_from() and also
|
||
joins to it using Query.join() would later cause an “ambiguous
|
||
FROM” error if that entity were used in additional joins, as the
|
||
entity appears twice in the “from” list of the Query. The fix
|
||
resolves this ambiguity by folding the standalone entity into
|
||
the join that it’s already a part of in the same way that
|
||
ultimately happens when the SELECT statement is rendered.
|
||
References: #4584
|
||
+ Adjusted the Query.filter_by() method to not call and()
|
||
internally against multiple criteria, instead passing it off to
|
||
Query.filter() as a series of criteria, instead of a single
|
||
criteria. This allows Query.filter_by() to defer to
|
||
Query.filter()’s treatment of variable numbers of clauses,
|
||
including the case where the list is empty. In this case, the
|
||
Query object will not have a .whereclause, which allows
|
||
subsequent “no whereclause” methods like Query.select_from() to
|
||
behave consistently. References: #4606
|
||
* postgresql
|
||
+ Fixed regression from release 1.3.2 caused by #4562 where a URL
|
||
that contained only a query string and no hostname, such as for
|
||
the purposes of specifying a service file with connection
|
||
information, would no longer be propagated to psycopg2
|
||
properly. The change in #4562 has been adjusted to further suit
|
||
psycopg2’s exact requirements, which is that if there are any
|
||
connection parameters whatsoever, the “dsn” parameter is no
|
||
longer required, so in this case the query string parameters are
|
||
passed alone. References: #4601
|
||
* mssql
|
||
+ Fixed issue in SQL Server dialect where if a bound parameter
|
||
were present in an ORDER BY expression that would ultimately not
|
||
be rendered in the SQL Server version of the statement, the
|
||
parameters would still be part of the execution parameters,
|
||
leading to DBAPI-level errors. Pull request courtesy Matt
|
||
Lewellyn. References: #4587
|
||
* misc
|
||
+ Fixed behavioral regression as a result of deprecating the
|
||
“use_threadlocal” flag for Pool, where the SingletonThreadPool
|
||
no longer makes use of this option which causes the “rollback on
|
||
return” logic to take place when the same Engine is used
|
||
multiple times in the context of a transaction to connect or
|
||
implicitly execute, thereby cancelling the transaction. While
|
||
this is not the recommended way to work with engines and
|
||
connections, it is nonetheless a confusing behavioral change as
|
||
when using SingletonThreadPool, the transaction should stay open
|
||
regardless of what else is done with the same engine in the same
|
||
thread. The use_threadlocal flag remains deprecated however the
|
||
SingletonThreadPool now implements its own version of the same
|
||
logic. References: #4585
|
||
+ Fixed bug where using copy.copy() or copy.deepcopy() on
|
||
MutableList would cause the items within the list to be
|
||
duplicated, due to an inconsistency in how Python pickle and
|
||
copy both make use of __getstate__() and __setstate__()
|
||
regarding lists. In order to resolve, a __reduce_ex__ method had
|
||
to be added to MutableList. In order to maintain backwards
|
||
compatibility with existing pickles based on __getstate__(), the
|
||
__setstate__() method remains as well; the test suite asserts
|
||
that pickles made against the old version of the class can still
|
||
be deserialized by the pickle module. References: #4603
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Apr 10 15:37:48 UTC 2019 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.3.2:
|
||
* orm
|
||
+ [orm] [bug] [ext] Restored instance-level support for plain
|
||
Python descriptors, e.g. @property objects, in conjunction with
|
||
association proxies, in that if the proxied object is not within
|
||
ORM scope at all, it gets classified as “ambiguous” but is
|
||
proxed directly. For class level access, a basic class
|
||
level"__get__()" now returns the
|
||
AmbiguousAssociationProxyInstance directly, rather than raising
|
||
its exception, which is the closest approximation to the
|
||
previous behavior that returned the AssociationProxy itself
|
||
that’s possible. Also improved the stringification of these
|
||
objects to be more descriptive of current state. References:
|
||
#4573, #4574
|
||
+ [orm] [bug] Fixed bug where use of with_polymorphic() or other
|
||
aliased construct would not properly adapt when the aliased
|
||
target were used as the Select.correlate_except() target of a
|
||
subquery used inside of a column_property(). This required a fix
|
||
to the clause adaption mechanics to properly handle a selectable
|
||
that shows up in the “correlate except” list, in a similar
|
||
manner as which occurs for selectables that show up in the
|
||
“correlate” list. This is ultimately a fairly fundamental bug
|
||
that has lasted for a long time but it is hard to come across
|
||
it. References: #4537
|
||
+ [orm] [bug] Fixed regression where a new error message that was
|
||
supposed to raise when attempting to link a relationship option
|
||
to an AliasedClass without using PropComparator.of_type() would
|
||
instead raise an AttributeError. Note that in 1.3, it is no
|
||
longer valid to create an option path from a plain mapper
|
||
relationship to an AliasedClass without using
|
||
PropComparator.of_type(). References: #4566
|
||
* sql
|
||
+ [sql] [bug] [documentation] Thanks to TypeEngine methods
|
||
bind_expression, column_expression work with Variant,
|
||
type-specific types, we no longer need to rely on recipes that
|
||
subclass dialect-specific types directly, TypeDecorator can now
|
||
handle all cases. Additionally, the above change made it
|
||
slightly less likely that a direct subclass of a base SQLAlchemy
|
||
type would work as expected, which could be
|
||
misleading. Documentation has been updated to use TypeDecorator
|
||
for these examples including the PostgreSQL “ArrayOfEnum”
|
||
example datatype and direct support for the “subclass a type
|
||
directly” has been removed. References: #4580
|
||
* postgresql
|
||
+ [postgresql] [feature] Added support for parameter-less
|
||
connection URLs for the psycopg2 dialect, meaning, the URL can
|
||
be passed to create_engine() as "postgresql+psycopg2://" with no
|
||
additional arguments to indicate an empty DSN passed to libpq,
|
||
which indicates to connect to “localhost” with no username,
|
||
password, or database given. Pull request courtesy Julian
|
||
Mehnle. References: #4562
|
||
+ [postgresql] [bug] Modified the Select.with_for_update.of
|
||
parameter so that if a join or other composed selectable is
|
||
passed, the individual Table objects will be filtered from it,
|
||
allowing one to pass a join() object to the parameter, as occurs
|
||
normally when using joined table inheritance with the ORM. Pull
|
||
request courtesy Raymond Lu. References: #4550
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Mar 10 16:34:50 UTC 2019 - Arun Persaud <arun@gmx.de>
|
||
|
||
- specfile:
|
||
* removed test.patch (included upstream)
|
||
|
||
- update to version 1.3.1:
|
||
* orm
|
||
+ [orm] [bug] [ext] Fixed regression where an association proxy
|
||
linked to a synonym would no longer work, both at instance level
|
||
and at class level. References: #4522
|
||
* mssql
|
||
+ [mssql] [bug] A commit() is emitted after an isolation level
|
||
change to SNAPSHOT, as both pyodbc and pymssql open an implicit
|
||
transaction which blocks subsequent SQL from being emitted in
|
||
the current transaction. References: #4536
|
||
+ [mssql] [bug] Fixed regression in SQL Server reflection due to
|
||
#4393 where the removal of open-ended **kw from the Float
|
||
datatype caused reflection of this type to fail due to a “scale”
|
||
argument being passed. References: #4525
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Mar 6 13:27:40 UTC 2019 - Tomáš Chvátal <tchvatal@suse.com>
|
||
|
||
- Add patch to fix test failure from upstream test.patch
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Mar 6 10:29:05 UTC 2019 - Tomáš Chvátal <tchvatal@suse.com>
|
||
|
||
- Update to versrion 1.3.0 (bsc#1124593, CVE-2019-7164, CVE-2019-7548):
|
||
* See https://docs.sqlalchemy.org/en/latest/changelog/migration_13.html
|
||
for deprecation list with this version
|
||
* For the changes see https://docs.sqlalchemy.org/en/latest/changelog/changelog_13.html
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Feb 22 13:05:14 UTC 2019 - John Vandenberg <jayvdb@gmail.com>
|
||
|
||
- Re-add build dependency on python-devel, removed December 2018,
|
||
used for optional C extensions cprocessors.so, cresultproxy.so and cutils.so.
|
||
- update to v1.2.18
|
||
Bugfix releases, find details at
|
||
https://docs.sqlalchemy.org/en/latest/changelog/changelog_12.html#change-1.2.18
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Feb 21 08:35:33 UTC 2019 - Adrian Schröter <adrian@suse.de>
|
||
|
||
- version update to 1.2.17
|
||
https://docs.sqlalchemy.org/en/latest/changelog/changelog_12.html
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Feb 9 14:00:31 UTC 2019 - Adrian Schröter <adrian@suse.de>
|
||
|
||
- update to version 1.2.16:
|
||
Bugfix releases, find details at
|
||
https://docs.sqlalchemy.org/en/latest/changelog/changelog_12.html#change-1.2.16
|
||
https://docs.sqlalchemy.org/en/latest/changelog/changelog_12.html#change-1.2.15
|
||
- 1.2.16 includes the fix to maintain compiled_params / replacement_expressions
|
||
within expanding IN (bsc#1176953)
|
||
|
||
-------------------------------------------------------------------
|
||
Tue Dec 4 12:54:53 UTC 2018 - Matej Cepl <mcepl@suse.com>
|
||
|
||
- Remove superfluous devel dependency for noarch package
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Nov 12 06:16:33 UTC 2018 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.2.14:
|
||
* orm
|
||
+ [orm] [bug] Fixed bug in Session.bulk_update_mappings() where
|
||
alternate mapped attribute names would result in the primary key
|
||
column of the UPDATE statement being included in the SET clause,
|
||
as well as the WHERE clause; while usually harmless, for SQL
|
||
Server this can raise an error due to the IDENTITY column. This
|
||
is a continuation of the same bug that was fixed in #3849, where
|
||
testing was insufficient to catch this additional flaw.
|
||
References: #4357
|
||
+ [orm] [bug] Fixed a minor performance issue which could in some
|
||
cases add unnecessary overhead to result fetching, involving the
|
||
use of ORM columns and entities that include those same columns
|
||
at the same time within a query. The issue has to do with hash /
|
||
eq overhead when referring to the column in different ways.
|
||
References: #4347
|
||
* mysql
|
||
+ [mysql] [bug] Fixed regression caused by #4344 released in
|
||
1.2.13, where the fix for MySQL 8.0’s case sensitivity problem
|
||
with referenced column names when reflecting foreign key
|
||
referents is worked around using the information_schema.columns
|
||
view. The workaround was failing on OSX /
|
||
lower_case_table_names=2 which produces non-matching casing for
|
||
the information_schema.columns vs. that of SHOW CREATE TABLE, so
|
||
in case-insensitive SQL modes case-insensitive matching is now
|
||
used. References: #4361
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Nov 1 22:48:27 UTC 2018 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.2.13:
|
||
* orm
|
||
+ [orm] [bug] Fixed bug where “dynamic” loader needs to explicitly
|
||
set the “secondary” table in the FROM clause of the query, to
|
||
suit the case where the secondary is a join object that is
|
||
otherwise not pulled into the query from its columns alone.
|
||
References: #4349
|
||
* orm declarative
|
||
+ [bug] [declarative] [orm] Fixed regression caused by #4326 in
|
||
version 1.2.12 where using declared_attr with a mixin in
|
||
conjunction with orm.synonym() would fail to map the synonym
|
||
properly to an inherited subclass. References: #4350
|
||
+ [bug] [declarative] [orm] The column conflict resolution
|
||
technique discussed at Resolving Column Conflicts is now
|
||
functional for a Column that is also a primary key
|
||
column. Previously, a check for primary key columns declared on
|
||
a single-inheritance subclass would occur before the column copy
|
||
were allowed to pass. References: #4352
|
||
* sql
|
||
+ [sql] [feature] Refactored SQLCompiler to expose a
|
||
SQLCompiler.group_by_clause() method similar to the
|
||
SQLCompiler.order_by_clause() and SQLCompiler.limit_clause()
|
||
methods, which can be overridden by dialects to customize how
|
||
GROUP BY renders. Pull request courtesy Samuel Chou.
|
||
+ [sql] [bug] Fixed bug where the Enum.create_constraint flag on
|
||
the Enum datatype would not be propagated to copies of the type,
|
||
which affects use cases such as declarative mixins and abstract
|
||
bases. References: #4341
|
||
* postgresql
|
||
+ [postgresql] [bug] Added support for the aggregate_order_by
|
||
function to receive multiple ORDER BY elements, previously only
|
||
a single element was accepted. References: #4337
|
||
* mysql
|
||
+ [mysql] [bug] Added word function to the list of reserved words
|
||
for MySQL, which is now a keyword in MySQL 8.0 References: #4348
|
||
+ [mysql] [bug] Added a workaround for a MySQL bug #88718
|
||
introduced in the 8.0 series, where the reflection of a foreign
|
||
key constraint is not reporting the correct case sensitivity for
|
||
the referred column, leading to errors during use of the
|
||
reflected constraint such as when using the automap
|
||
extension. The workaround emits an additional query to the
|
||
information_schema tables in order to retrieve the correct case
|
||
sensitive name. References: #4344
|
||
* misc
|
||
+ [misc] [bug] Fixed issue where part of the utility language
|
||
helper internals was passing the wrong kind of argument to the
|
||
Python __import__ builtin as the list of modules to be
|
||
imported. The issue produced no symptoms within the core library
|
||
but could cause issues with external applications that redefine
|
||
the __import__ builtin or otherwise instrument it. Pull request
|
||
courtesy Joe Urciuoli.
|
||
+ [misc] [bug] [py3k] Fixed additional warnings generated by
|
||
Python 3.7 due to changes in the organization of the Python
|
||
collections and collections.abc packages. Previous collections
|
||
warnings were fixed in version 1.2.11. Pull request courtesy
|
||
xtreak. References: #4339
|
||
+ [bug] [ext] Added missing .index() method to list-based
|
||
association collections in the association proxy extension.
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Sep 22 05:28:52 UTC 2018 - Arun Persaud <arun@gmx.de>
|
||
|
||
- update to version 1.2.12:
|
||
* orm
|
||
+ [orm] [bug] Added a check within the weakref cleanup for the
|
||
InstanceState object to check for the presence of the dict
|
||
builtin, in an effort to reduce error messages generated when
|
||
these cleanups occur during interpreter shutdown. Pull request
|
||
courtesy Romuald Brunet.
|
||
+ [orm] [bug] Fixed bug where use of Lateral construct in
|
||
conjunction with Query.join() as well as
|
||
Query.select_entity_from() would not apply clause adaption to
|
||
the right side of the join. “lateral” introduces the use case of
|
||
the right side of a join being correlatable. Previously,
|
||
adaptation of this clause wasn’t considered. Note that in 1.2
|
||
only, a selectable introduced by Query.subquery() is still not
|
||
adapted due to #4304; the selectable needs to be produced by the
|
||
select() function to be the right side of the “lateral” join.
|
||
References: #4334
|
||
+ [orm] [bug] Fixed 1.2 regression caused by #3472 where the
|
||
handling of an “updated_at” style column within the context of a
|
||
post-update operation would also occur for a row that is to be
|
||
deleted following the update, meaning both that a column with a
|
||
Python-side value generator would show the now-deleted value
|
||
that was emitted for the UPDATE before the DELETE (which was not
|
||
the previous behavor), as well as that a SQL- emitted value
|
||
generator would have the attribute expired, meaning the previous
|
||
value would be unreachable due to the row having been deleted
|
||
and the object detached from the session.The “postfetch” logic
|
||
that was added as part of #3472 is now skipped entirely for an
|
||
object that ultimately is to be deleted. References: #4327
|
||
* orm declarative
|
||
+ [bug] [declarative] [orm] Fixed bug where the declarative scan
|
||
for attributes would receive the expression proxy delivered by a
|
||
hybrid attribute at the class level, and not the hybrid
|
||
attribute itself, when receiving the descriptor via the
|
||
@declared_attr callable on a subclass of an already-mapped
|
||
class. This would lead to an attribute that did not report
|
||
itself as a hybrid when viewed within
|
||
Mapper.all_orm_descriptors. References: #4326
|
||
* postgresql
|
||
+ [postgresql] [bug] Fixed bug in PostgreSQL dialect where
|
||
compiler keyword arguments such as literal_binds=True were not
|
||
being propagated to a DISTINCT ON expression. References: #4325
|
||
+ [postgresql] [bug] Fixed the postgresql.array_agg() function,
|
||
which is a slightly altered version of the usual
|
||
functions.array_agg() function, to also accept an incoming
|
||
“type” argument without forcing an ARRAY around it, essentially
|
||
the same thing that was fixed for the generic function in 1.1 in
|
||
#4107. References: #4324
|
||
+ [postgresql] [bug] Fixed bug in PostgreSQL ENUM reflection where
|
||
a case-sensitive, quoted name would be reported by the query
|
||
including quotes, which would not match a target column during
|
||
table reflection as the quotes needed to be stripped off.
|
||
References: #4323
|
||
* oracle
|
||
+ [oracle] [bug] Fixed issue for cx_Oracle 7.0 where the behavior
|
||
of Oracle param.getvalue() now returns a list, rather than a
|
||
single scalar value, breaking autoincrement logic throughout the
|
||
Core and ORM. The dml_ret_array_val compatibility flag is used
|
||
for cx_Oracle 6.3 and 6.4 to establish compatible behavior with
|
||
7.0 and forward, for cx_Oracle 6.2.1 and prior a version number
|
||
check falls back to the old logic. References: #4335
|
||
* misc
|
||
+ [bug] [ext] Fixed issue where BakedQuery did not include the
|
||
specific query class used by the Session as part of the cache
|
||
key, leading to incompatibilities when using custom query
|
||
classes, in particular the ShardedQuery which has some different
|
||
argument signatures. References: #4328
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Aug 25 18:12:02 UTC 2018 - arun@gmx.de
|
||
|
||
- update to version 1.2.11:
|
||
* orm declarative
|
||
+ [bug] [declarative] [orm] Fixed issue in previously untested use
|
||
case, allowing a declarative mapped class to inherit from a
|
||
classically-mapped class outside of the declarative base,
|
||
including that it accommodates for unmapped intermediate
|
||
classes. An unmapped intermediate class may specify
|
||
__abstract__, which is now interpreted correctly, or the
|
||
intermediate class can remain unmarked, and the classically
|
||
mapped base class will be detected within the hierarchy
|
||
regardless. In order to anticipate existing scenarios which may
|
||
be mixing in classical mappings into existing declarative
|
||
hierarchies, an error is now raised if multiple mapped bases are
|
||
detected for a given class. References: #4321
|
||
* sql
|
||
+ [sql] [bug] Fixed issue that is closely related to #3639 where
|
||
an expression rendered in a boolean context on a non-native
|
||
boolean backend would be compared to 1/0 even though it is
|
||
already an implcitly boolean expression, when
|
||
ColumnElement.self_group() were used. While this does not affect
|
||
the user-friendly backends (MySQL, SQLite) it was not handled by
|
||
Oracle (and possibly SQL Server). Whether or not the expression
|
||
is implicitly boolean on any database is now determined up front
|
||
as an additional check to not generate the integer comparison
|
||
within the compliation of the statement. References: #4320
|
||
+ [sql] [bug] Added missing window function parameters
|
||
WithinGroup.over.range_ and WithinGroup.over.rows parameters to
|
||
the WithinGroup.over() and FunctionFilter.over() methods, to
|
||
correspond to the range/rows feature added to the “over” method
|
||
of SQL functions as part of #3049 in version 1.1. References:
|
||
#4322
|
||
+ [sql] [bug] Fixed bug where the multi-table support for UPDATE
|
||
and DELETE statements did not consider the additional FROM
|
||
elements as targets for correlation, when a correlated SELECT
|
||
were also combined with the statement. This change now includes
|
||
that a SELECT statement in the WHERE clause for such a statement
|
||
will try to auto-correlate back to these additional tables in
|
||
the parent UPDATE/DELETE or unconditionally correlate if
|
||
Select.correlate() is used. Note that auto-correlation raises an
|
||
error if the SELECT statement would have no FROM clauses as a
|
||
result, which can now occur if the parent UPDATE/DELETE
|
||
specifies the same tables in its additional set of tables;
|
||
specify Select.correlate() explicitly to resolve. References:
|
||
#4313
|
||
* oracle
|
||
+ [oracle] [bug] For cx_Oracle, Integer datatypes will now be
|
||
bound to “int”, per advice from the cx_Oracle
|
||
developers. Previously, using cx_Oracle.NUMBER caused a loss in
|
||
precision within the cx_Oracle 6.x series. References: #4309
|
||
* misc
|
||
+ [bug] [py3k] Started importing “collections” from
|
||
“collections.abc” under Python 3.3 and greater for Python 3.8
|
||
compatibility. Pull request courtesy Nathaniel Knight.
|
||
+ Fixed issue where the “schema” name used for a SQLite database
|
||
within table reflection would not quote the schema name
|
||
correctly. Pull request courtesy Phillip Cloud.
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Jul 14 01:56:32 UTC 2018 - arun@gmx.de
|
||
|
||
- update to version 1.2.10:
|
||
* orm
|
||
+ [orm] [bug] Fixed bug in Bundle construct where placing two
|
||
columns of the same name would be de-duplicated, when the Bundle
|
||
were used as part of the rendered SQL, such as in the ORDER BY
|
||
or GROUP BY of the statement. References: #4295
|
||
+ [orm] [bug] Fixed regression in 1.2.9 due to #4287 where using a
|
||
Load option in conjunction with a string wildcard would result
|
||
in a TypeError. References: #4298
|
||
* sql
|
||
+ [sql] [bug] Fixed bug where a Sequence would be dropped
|
||
explicitly before any Table that refers to it, which breaks in
|
||
the case when the sequence is also involved in a server-side
|
||
default for that table, when using MetaData.drop_all(). The step
|
||
which processes sequences to be dropped via non server-side
|
||
column default functions is now invoked after the table itself
|
||
is dropped. References: #4300
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Jul 1 02:17:55 UTC 2018 - arun@gmx.de
|
||
|
||
- removed patch fix_test_reflection.patch (included upstream)
|
||
|
||
- update to version 1.2.9:
|
||
* orm
|
||
+ [orm] [bug] Fixed issue where chaining multiple join elements
|
||
inside of Query.join() might not correctly adapt to the previous
|
||
left-hand side, when chaining joined inheritance classes that
|
||
share the same base class.
|
||
References: #3505
|
||
+ [orm] [bug] Fixed bug in cache key generation for baked queries
|
||
which could cause a too-short cache key to be generated for the
|
||
case of eager loads across subclasses. This could in turn cause
|
||
the eagerload query to be cached in place of a non-eagerload
|
||
query, or vice versa, for a polymorhic “selectin” load, or
|
||
possibly for lazy loads or selectin loads as well.
|
||
References: #4287
|
||
+ [orm] [bug] Fixed bug in new polymorphic selectin loading where
|
||
the BakedQuery used internally would be mutated by the given
|
||
loader options, which would both inappropriately mutate the
|
||
subclass query as well as carry over the effect to subsequent
|
||
queries.
|
||
References: #4286
|
||
+ [orm] [bug] Fixed regression caused by #4256 (itself a
|
||
regression fix for #4228) which breaks an undocumented behavior
|
||
which converted for a non-sequence of entities passed directly
|
||
to the Query constructor into a single-element sequence. While
|
||
this behavior was never supported or documented, it’s already in
|
||
use so has been added as a behavioral contract to Query.
|
||
References: #4269
|
||
+ [orm] [bug] Fixed an issue that was both a performance
|
||
regression in 1.2 as well as an incorrect result regarding the
|
||
“baked” lazy loader, involving the generation of cache keys from
|
||
the original Query object’s loader options. If the loader
|
||
options were built up in a “branched” style using common base
|
||
elements for multiple options, the same options would be
|
||
rendered into the cache key repeatedly, causing both a
|
||
performance issue as well as generating the wrong cache
|
||
key. This is fixed, along with a performance improvement when
|
||
such “branched” options are applied via Query.options() to
|
||
prevent the same option objects from being applied repeatedly.
|
||
References: #4270
|
||
* sql
|
||
+ [sql] [bug] Fixed regression in 1.2 due to #4147 where a Table
|
||
that has had some of its indexed columns redefined with new
|
||
ones, as would occur when overriding columns during reflection
|
||
or when using Table.extend_existing, such that the
|
||
Table.tometadata() method would fail when attempting to copy
|
||
those indexes as they still referred to the replaced column. The
|
||
copy logic now accommodates for this condition.
|
||
References: #4279
|
||
* mysql
|
||
+ [mysql] [bug] Fixed percent-sign doubling in
|
||
mysql-connector-python dialect, which does not require
|
||
de-doubling of percent signs. Additionally, the mysql-
|
||
connector-python driver is inconsistent in how it passes the
|
||
column names in cursor.description, so a workaround decoder has
|
||
been added to conditionally decode these
|
||
randomly-sometimes-bytes values to unicode only if needed. Also
|
||
improved test support for mysql-connector-python, however it
|
||
should be noted that this driver still has issues with unicode
|
||
that continue to be unresolved as of yet.
|
||
+ [mysql] [bug] Fixed bug in index reflection where on MySQL 8.0
|
||
an index that includes ASC or DESC in an indexed column
|
||
specfication would not be correctly reflected, as MySQL 8.0
|
||
introduces support for returning this information in a table
|
||
definition string.
|
||
References: #4293
|
||
+ [mysql] [bug] Fixed bug in MySQLdb dialect and variants such as
|
||
PyMySQL where an additional “unicode returns” check upon
|
||
connection makes explicit use of the “utf8” character set, which
|
||
in MySQL 8.0 emits a warning that utf8mb4 should be used. This
|
||
is now replaced with a utf8mb4 equivalent. Documentation is also
|
||
updated for the MySQL dialect to specify utf8mb4 in all
|
||
examples. Additional changes have been made to the test suite to
|
||
use utf8mb3 charsets and databases (there seem to be collation
|
||
issues in some edge cases with utf8mb4), and to support
|
||
configuration default changes made in MySQL 8.0 such as
|
||
explicit_defaults_for_timestamp as well as new errors raised for
|
||
invalid MyISAM indexes.
|
||
References: #4283
|
||
+ [mysql] [bug] The Update construct now accommodates a Join
|
||
object as supported by MySQL for UPDATE..FROM. As the construct
|
||
already accepted an alias object for a similar purpose, the
|
||
feature of UPDATE against a non-table was already implied so
|
||
this has been added.
|
||
References: #3645
|
||
* sqlite
|
||
+ [sqlite] [bug] Fixed issue in test suite where SQLite 3.24 added
|
||
a new reserved word that conflicted with a usage in
|
||
TypeReflectionTest. Pull request courtesy Nils Philippsen.
|
||
* mssql
|
||
+ [mssql] [bug] Fixed bug in MSSQL reflection where when two
|
||
same-named tables in different schemas had same-named primary
|
||
key constraints, foreign key constraints referring to one of the
|
||
tables would have their columns doubled, causing errors. Pull
|
||
request courtesy Sean Dunn.
|
||
References: #4228
|
||
+ [mssql] [bug] [py3k] Fixed issue within the SQL Server dialect
|
||
under Python 3 where when running against a non-standard SQL
|
||
server database that does not contain either the
|
||
“sys.dm_exec_sessions” or “sys.dm_pdw_nodes_exec_sessions”
|
||
views, leading to a failure to fetch the isolation level, the
|
||
error raise would fail due to an UnboundLocalError.
|
||
References: #4273
|
||
* oracle
|
||
+ [oracle] [feature] Added a new event currently used only by the
|
||
cx_Oracle dialect, DialectEvents.setiputsizes(). The event
|
||
passes a dictionary of BindParameter objects to DBAPI-specific
|
||
type objects that will be passed, after conversion to parameter
|
||
names, to the cx_Oracle cursor.setinputsizes() method. This
|
||
allows both visibility into the setinputsizes process as well as
|
||
the ability to alter the behavior of what datatypes are passed
|
||
to this method.
|
||
See als Fine grained control over cx_Oracle data binding and performance with setinputsizes
|
||
References: #4290
|
||
+ [oracle] [bug] [mysql] Fixed INSERT FROM SELECT with CTEs for
|
||
the Oracle and MySQL dialects, where the CTE was being placed
|
||
above the entire statement as is typical with other databases,
|
||
however Oracle and MariaDB 10.2 wants the CTE underneath the
|
||
“INSERT” segment. Note that the Oracle and MySQL dialects don’t
|
||
yet work when a CTE is applied to a subquery inside of an UPDATE
|
||
or DELETE statement, as the CTE is still applied to the top
|
||
rather than inside the subquery.
|
||
References: #4275
|
||
* misc
|
||
+ [feature] [ext] Added new attribute Query.lazy_loaded_from which
|
||
is populated with an InstanceState that is using this Query in
|
||
order to lazy load a relationship. The rationale for this is
|
||
that it serves as a hint for the horizontal sharding feature to
|
||
use, such that the identity token of the state can be used as
|
||
the default identity token to use for the query within
|
||
id_chooser().
|
||
References: #4243
|
||
+ [bug] [py3k] Replaced the usage of inspect.formatargspec() with
|
||
a vendored version copied from the Python standard library, as
|
||
inspect.formatargspec() is deprecated and as of Python 3.7.0 is
|
||
emitting a warning.
|
||
References: #4291
|
||
|
||
-------------------------------------------------------------------
|
||
Tue Jun 26 06:55:57 UTC 2018 - mimi.vx@gmail.com
|
||
|
||
- add upstream fix_test_reflection.patch to fix tests with new sqlite
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Jun 21 23:01:18 UTC 2018 - hpj@urpla.net
|
||
|
||
- update to version 1.2.8:
|
||
* orm
|
||
+ [orm] [bug] Fixed regression in 1.2.7 caused by #4228, which
|
||
itself was fixing a 1.2-level regression, where the query_cls
|
||
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.
|
||
References: #4256
|
||
+ [orm] [bug] Fixed a long-standing regression that occurred in
|
||
version 1.0, which prevented the use of a custom MapperOption
|
||
that alters the _params of a Query object for a lazy load,
|
||
since the lazy loader itself would overwrite those parameters.
|
||
This applies to the “temporal range” example on the wiki. Note
|
||
however that the Query.populate_existing() method is now
|
||
required in order to rewrite the mapper options associated with
|
||
an object already loaded in the identity map.
|
||
As part of this change, a custom defined MapperOption will now
|
||
cause lazy loaders related to the target object to use a non-
|
||
baked query by default unless the
|
||
MapperOption._generate_cache_key() method is implemented. In
|
||
particular, this repairs one regression which occured when
|
||
using the dogpile.cache “advanced” example, which was not
|
||
returning cached results and instead emitting SQL due to an
|
||
incompatibility with the baked query loader; with the change,
|
||
the RelationshipCache option included for many releases in the
|
||
dogpile example will disable the “baked” query altogether. Note
|
||
that the dogpile example is also modernized to avoid both of
|
||
these issues as part of issue #4258. References: #4128
|
||
+ [orm] [bug] Fixed bug where the new
|
||
baked.Result.with_post_criteria() method would not interact
|
||
with a subquery-eager loader correctly, in that the “post
|
||
criteria” would not be applied to embedded subquery
|
||
eager loaders. This is related to #4128 in that the post
|
||
criteria feature is now used by the lazy loader.
|
||
+ [orm] [bug] Updated the dogpile.caching example to include new
|
||
structures that accommodate for the “baked” query system, which
|
||
is used by default within lazy loaders and some eager
|
||
relationship loaders. The dogpile.caching “relationship_caching”
|
||
and “advanced” examples were also broken due to #4256. The
|
||
issue here is also worked-around by the fix in #4128.
|
||
References: #4258
|
||
* engine
|
||
+ [engine] [bug] Fixed connection pool issue whereby if a
|
||
disconnection error were raised during the connection pool’s
|
||
“reset on return” sequence in conjunction with an explicit
|
||
transaction opened against the enclosing Connection object
|
||
(such as from calling Session.close() without a rollback or
|
||
commit, or calling Connection.close() without first closing a
|
||
transaction declared with Connection.begin()), a double-checkin
|
||
would result, which could then lead towards concurrent
|
||
checkouts of the same connection. The double-checkin condition
|
||
is now prevented overall by an assertion, as well as the
|
||
specific double-checkin scenario has been fixed.
|
||
References: #4252
|
||
+ [engine] [bug] Fixed a reference leak issue where the values of
|
||
the parameter dictionary used in a statement execution would
|
||
remain referenced by the “compiled cache”, as a result of
|
||
storing the key view used by Python 3 dictionary keys(). Pull
|
||
request courtesy Olivier Grisel.
|
||
* sql
|
||
+ [sql] [bug] Fixed issue where the “ambiguous literal” error
|
||
message used when interpreting literal values as SQL expression
|
||
values would encounter a tuple value, and fail to format the
|
||
message properly. Pull request courtesy Miguel Ventura.
|
||
* mssql
|
||
+ [mssql] [bug] Fixed a 1.2 regression caused by #4061 where the
|
||
SQL Server “BIT” type would be considered to be “native
|
||
boolean”. The goal here was to avoid creating a CHECK
|
||
constraint on the column, however the bigger issue is that the
|
||
BIT value does not behave like a true/false constant and cannot
|
||
be interpreted as a standalone expression, e.g. “WHERE
|
||
<column>”. The SQL Server dialect now goes back to being non-
|
||
native boolean, but with an extra flag that still avoids
|
||
creating the CHECK constraint. References: #4250
|
||
* oracle
|
||
+ [oracle] [bug] The Oracle BINARY_FLOAT and BINARY_DOUBLE
|
||
datatypes now participate within cx_Oracle.setinputsizes(),
|
||
passing along NATIVE_FLOAT, so as to support the NaN value.
|
||
Additionally, oracle.BINARY_FLOAT, oracle.BINARY_DOUBLE and
|
||
oracle.DOUBLE_PRECISION now subclass Float, since these are
|
||
floating point datatypes, not decimal. These datatypes were
|
||
already defaulting the Float.asdecimal flag to False in line
|
||
with what Float already does. References: #4264
|
||
+ [oracle] [bug] Added reflection capabilities for the
|
||
oracle.BINARY_FLOAT, oracle.BINARY_DOUBLE datatypes.
|
||
+ [oracle] [bug] Altered the Oracle dialect such that when an
|
||
Integer type is in use, the cx_Oracle.NUMERIC type is set up
|
||
for setinputsizes(). In SQLAlchemy 1.1 and earlier,
|
||
cx_Oracle.NUMERIC was passed for all numeric types
|
||
unconditionally, and in 1.2 this was removed to allow for
|
||
better numeric precision. However, for integers, some
|
||
database/client setups will fail to coerce boolean values
|
||
True/False into integers which introduces regressive behavior
|
||
when using SQLAlchemy 1.2. Overall, the setinputsizes logic
|
||
seems like it will need a lot more flexibility going forward so
|
||
this is a start for that. References: #4259
|
||
* misc
|
||
+ [bug] [ext] The horizontal sharding extension now makes use of
|
||
the identity token added to ORM identity keys as part of #4137,
|
||
when an object refresh or column-based deferred load or
|
||
unexpiration operation occurs. Since we know the “shard” that
|
||
the object originated from, we make use of this value when
|
||
refreshing, thereby avoiding queries against other shards that
|
||
don’t match this object’s identity in any case.
|
||
References: #4247
|
||
+ [bug] [ext] Fixed a race condition which could occur if automap
|
||
AutomapBase.prepare() were used within a multi-threaded context
|
||
against other threads which may call configure_mappers() as a
|
||
result of use of other mappers. The unfinished mapping work of
|
||
automap is particularly sensitive to being pulled in by a
|
||
configure_mappers() step leading to errors. References: #4266
|
||
+ [bug] [tests] Fixed a bug in the test suite where if an
|
||
external dialect returned None for server_version_info, the
|
||
exclusion logic would raise an AttributeError.
|
||
References: #4249
|
||
|
||
-------------------------------------------------------------------
|
||
Sat Apr 21 16:35:48 UTC 2018 - arun@gmx.de
|
||
|
||
- update to version 1.2.7:
|
||
* orm
|
||
+ [orm] [bug] Fixed regression in 1.2 within sharded query feature
|
||
where the new “identity_token” element was not being correctly
|
||
considered within the scope of a lazy load operation, when
|
||
searching the identity map for a related many-to-one
|
||
element. The new behavior will allow for making use of the
|
||
“id_chooser” in order to determine the best identity key to
|
||
retrieve from the identity map. In order to achieve this, some
|
||
refactoring of 1.2’s “identity_token” approach has made some
|
||
slight changes to the implementation of ShardedQuery which
|
||
should be noted for other derivations of this class.
|
||
References: #4228
|
||
+ [orm] [bug] Fixed issue in single-inheritance loading where the
|
||
use of an aliased entity against a single-inheritance subclass
|
||
in conjunction with the Query.select_from() method would cause
|
||
the SQL to be rendered with the unaliased table mixed in to the
|
||
query, causing a cartesian product. In particular this was
|
||
affecting the new “selectin” loader when used against a
|
||
single-inheritance subclass. References: #4241
|
||
* sql
|
||
+ [sql] [bug] Fixed issue where the compilation of an INSERT
|
||
statement with the “literal_binds” option that also uses an
|
||
explicit sequence and “inline” generation, as on Postgresql and
|
||
Oracle, would fail to accommodate the extra keyword argument
|
||
within the sequence processing routine. References: #4231
|
||
* postgresql
|
||
+ [postgresql] [feature] Added new PG type postgresql.REGCLASS
|
||
which assists in casting table names to OID values. Pull request
|
||
courtesy Sebastian Bank. References: #4160
|
||
+ [postgresql] [bug] Fixed bug where the special “not equals”
|
||
operator for the Postgresql “range” datatypes such as DATERANGE
|
||
would fail to render “IS NOT NULL” when compared to the Python
|
||
None value. References: #4229
|
||
* mssql
|
||
+ [mssql] [bug] Fixed 1.2 regression caused by #4060 where the
|
||
query used to reflect SQL Server cross-schema foreign keys was
|
||
limiting the criteria incorrectly. References: #4234
|
||
* oracle
|
||
+ [oracle] [bug] The Oracle NUMBER datatype is reflected as
|
||
INTEGER if the precision is NULL and the scale is zero, as this
|
||
is how INTEGER values come back when reflected from Oracle’s
|
||
tables. Pull request courtesy Kent Bower.
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Apr 1 22:17:46 UTC 2018 - arun@gmx.de
|
||
|
||
- specfile:
|
||
* run spec-cleaner
|
||
|
||
- update to version 1.2.6:
|
||
* orm
|
||
+ [orm] [bug] Fixed bug where using Mutable.associate_with() or
|
||
Mutable.as_mutable() in conjunction with a class that has non-
|
||
primary mappers set up with alternatively-named attributes would
|
||
produce an attribute error. Since non-primary mappers are not
|
||
used for persistence, the mutable extension now excludes
|
||
non-primary mappers from its instrumentation steps. References:
|
||
#4215
|
||
* engine
|
||
+ [engine] [bug] Fixed bug in connection pool where a connection
|
||
could be present in the pool without all of its “connect” event
|
||
handlers called, if a previous “connect” handler threw an
|
||
exception; note that the dialects themselves have connect
|
||
handlers that emit SQL, such as those which set transaction
|
||
isolation, which can fail if the database is in a non-available
|
||
state, but still allows a connection. The connection is now
|
||
invalidated first if any of the connect handlers fail.
|
||
References: #4225
|
||
* sql
|
||
+ [sql] [bug] Fixed a regression that occurred from the previous
|
||
fix to #4204 in version 1.2.5, where a CTE that refers to itself
|
||
after the CTE.alias() method has been called would not refer to
|
||
iself correctly. References: #4204
|
||
* postgresql
|
||
+ [postgresql] [feature] Added support for “PARTITION BY” in
|
||
Postgresql table definitions, using
|
||
“postgresql_partition_by”. Pull request courtesy Vsevolod
|
||
Solovyov.
|
||
* mssql
|
||
+ [mssql] [bug] Adjusted the SQL Server version detection for
|
||
pyodbc to only allow for numeric tokens, filtering out
|
||
non-integers, since the dialect does tuple- numeric comparisons
|
||
with this value. This is normally true for all known SQL Server
|
||
/ pyodbc drivers in any case. References: #4227
|
||
* oracle
|
||
+ [oracle] [bug] The minimum cx_Oracle version supported is 5.2
|
||
(June 2015). Previously, the dialect asserted against version
|
||
5.0 but as of 1.2.2 we are using some symbols that did not
|
||
appear until 5.2. References: #4211
|
||
* misc
|
||
+ [bug] [declarative] Removed a warning that would be emitted when
|
||
calling upon __table_args__, __mapper_args__ as named with a
|
||
@declared_attr method, when called from a non-mapped declarative
|
||
mixin. Calling these directly is documented as the approach to
|
||
use when one is overidding one of these methods on a mapped
|
||
class. The warning still emits for regular attribute names.
|
||
References: #4221
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Mar 8 04:50:46 UTC 2018 - arun@gmx.de
|
||
|
||
- update to version 1.2.5:
|
||
* orm
|
||
+ [orm] [feature] Added new feature
|
||
Query.only_return_tuples(). Causes the Query object to return
|
||
keyed tuple objects unconditionally even if the query is against
|
||
a single entity. Pull request courtesy Eric Atkin.
|
||
+ [orm] [bug] Fixed bug in new “polymorphic selectin” loading when
|
||
a selection of polymorphic objects were to be partially loaded
|
||
from a relationship lazy loader, leading to an “empty IN”
|
||
condition within the load that raises an error for the “inline”
|
||
form of “IN”. References: #4199
|
||
+ [orm] [bug] Fixed 1.2 regression where a mapper option that
|
||
contains an AliasedClass object, as is typical when using the
|
||
QueryableAttribute.of_type() method, could not be pickled. 1.1’s
|
||
behavior was to omit the aliased class objects from the path, so
|
||
this behavior is restored. References: #4209
|
||
* sql
|
||
+ [sql] [bug] Fixed bug in :class:.`CTE` construct along the same
|
||
lines as that of #4204 where a CTE that was aliased would not
|
||
copy itself correctly during a “clone” operation as is frequent
|
||
within the ORM as well as when using the ClauseElement.params()
|
||
method. References: #4210
|
||
+ [sql] [bug] Fixed bug in CTE rendering where a CTE that was also
|
||
turned into an Alias would not render its “ctename AS aliasname”
|
||
clause appropriately if there were more than one reference to
|
||
the CTE in a FROM clause. References: #4204
|
||
+ [sql] [bug] Fixed bug in new “expanding IN parameter” feature
|
||
where the bind parameter processors for values wasn’t working at
|
||
all, tests failed to cover this pretty basic case which includes
|
||
that ENUM values weren’t working. References: #4198
|
||
* postgresql
|
||
+ [postgresql] [bug] [py3k] Fixed bug in Postgresql COLLATE /
|
||
ARRAY adjustment first introduced in #4006 where new behaviors
|
||
in Python 3.7 regular expressions caused the fix to fail. This
|
||
change is also backported to: 1.1.18 References: #4208
|
||
* mysql
|
||
+ [mysql] [bug] MySQL dialects now query the server version using
|
||
SELECT @@version explicitly to the server to ensure we are
|
||
getting the correct version information back. Proxy servers like
|
||
MaxScale interfere with the value that is passed to the DBAPI’s
|
||
connection.server_version value so this is no longer reliable.
|
||
This change is also backported to: 1.1.18 References: #4205
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Feb 23 23:48:41 UTC 2018 - arun@gmx.de
|
||
|
||
- update to version 1.2.4:
|
||
* orm
|
||
+ [orm] [bug] Fixed 1.2 regression in ORM versioning feature where
|
||
a mapping against a select() or alias() that also used a
|
||
versioning column against the underlying table would fail due to
|
||
the check added as part of #3673. References: #4193
|
||
* engine
|
||
+ [engine] [bug] Fixed regression caused in 1.2.3 due to fix from
|
||
#4181 where the changes to the event system involving Engine and
|
||
OptionEngine did not accommodate for event removals, which would
|
||
raise an AttributeError when invoked at the class level.
|
||
References: #4190
|
||
* sql
|
||
+ [sql] [bug] Fixed bug where CTE expressions would not have their
|
||
name or alias name quoted when the given name is case sensitive
|
||
or otherwise requires quoting. Pull request courtesy Eric Atkin.
|
||
References: #4197
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Feb 18 17:09:28 UTC 2018 - arun@gmx.de
|
||
|
||
- update to version 1.2.3:
|
||
* orm
|
||
+ [orm] [feature] Added new argument
|
||
attributes.set_attribute.inititator to the
|
||
attributes.set_attribute() function, allowing an event token
|
||
received from a listener function to be propagated to subsequent
|
||
set events.
|
||
+ [orm] [bug] Fixed issue in post_update feature where an UPDATE
|
||
is emitted when the parent object has been deleted but the
|
||
dependent object is not. This issue has existed for a long time
|
||
however since 1.2 now asserts rows matched for post_update, this
|
||
was raising an error. This change is also backported to: 1.1.16
|
||
References: #4187
|
||
+ [orm] [bug] Fixed regression caused by fix for issue #4116
|
||
affecting versions 1.2.2 as well as 1.1.15, which had the effect
|
||
of mis-calculation of the “owning class” of an AssociationProxy
|
||
as the NoneType class in some declarative mixin/inheritance
|
||
situations as well as if the association proxy were accessed off
|
||
of an un-mapped class. The “figure out the owner” logic has been
|
||
replaced by an in-depth routine that searches through the
|
||
complete mapper hierarchy assigned to the class or subclass to
|
||
determine the correct (we hope) match; will not assign the owner
|
||
if no match is found. An exception is now raised if the proxy is
|
||
used against an un-mapped instance. This change is also
|
||
backported to: 1.1.16 References: #4185
|
||
+ [orm] [bug] Fixed bug where the Bundle object did not correctly
|
||
report upon the primary Mapper object represened by the bundle,
|
||
if any. An immediate side effect of this issue was that the new
|
||
selectinload loader strategy wouldn’t work with the horizontal
|
||
sharding extension. References: #4175
|
||
+ [orm] [bug] Fixed bug in concrete inheritance mapping where
|
||
user-defined attributes such as hybrid properties that mirror
|
||
the names of mapped attributes from sibling classes would be
|
||
overwritten by the mapper as non-accessible at the instance
|
||
level. Additionally ensured that user-bound descriptors are not
|
||
implicitly invoked at the class level during the mapper
|
||
configuration stage. References: #4188
|
||
+ [orm] [bug] Fixed bug where the orm.reconstructor() event helper
|
||
would not be recognized if it were applied to the __init__()
|
||
method of the mapped class. References: #4178
|
||
* engine
|
||
+ [engine] [bug] Fixed bug where events associated with an Engine
|
||
at the class level would be doubled when the
|
||
Engine.execution_options() method were used. To achieve this,
|
||
the semi-private class OptionEngine no longer accepts events
|
||
directly at the class level and will raise an error; the class
|
||
only propagates class-level events from its parent
|
||
Engine. Instance-level events continue to work as before.
|
||
References: #4181
|
||
+ [engine] [bug] The URL object now allows query keys to be
|
||
specified multiple times where their values will be joined into
|
||
a list. This is to support the plugins feature documented at
|
||
CreateEnginePlugin which documents that “plugin” can be passed
|
||
multiple times. Additionally, the plugin names can be passed to
|
||
create_engine() outside of the URL using the new
|
||
create_engine.plugins parameter. References: #4170
|
||
* sql
|
||
+ [sql] [feature] Added support for Enum to persist the values of
|
||
the enumeration, rather than the keys, when using a Python
|
||
pep-435 style enumerated object. The user supplies a callable
|
||
function that will return the string values to be
|
||
persisted. This allows enumerations against non-string values to
|
||
be value-persistable as well. Pull request courtesy Jon Snyder.
|
||
References: #3906
|
||
+ [sql] [bug] Fixed bug where the Enum type wouldn’t handle enum
|
||
“aliases” correctly, when more than one key refers to the same
|
||
value. Pull request courtesy Daniel Knell. References: #4180
|
||
* postgresql
|
||
+ [postgresql] [bug] Added “SSL SYSCALL error: Operation timed
|
||
out” to the list of messages that trigger a “disconnect”
|
||
scenario for the psycopg2 driver. Pull request courtesy André
|
||
Cruz. This change is also backported to: 1.1.16
|
||
+ [postgresql] [bug] Added “TRUNCATE” to the list of keywords
|
||
accepted by the Postgresql dialect as an “autocommit”-triggering
|
||
keyword. Pull request courtesy Jacob Hayes. This change is also
|
||
backported to: 1.1.16
|
||
* sqlite
|
||
+ [sqlite] [bug] Fixed the import error raised when a platform has
|
||
neither pysqlite2 nor sqlite3 installed, such that the
|
||
sqlite3-related import error is raised, not the pysqlite2 one
|
||
which is not the actual failure mode. Pull request courtesy
|
||
Robin.
|
||
* oracle
|
||
+ [oracle] [feature] The ON DELETE options for foreign keys are
|
||
now part of Oracle reflection. Oracle does not support ON UPDATE
|
||
cascades. Pull request courtesy Miroslav Shubernetskiy.
|
||
+ [oracle] [bug] Fixed bug in cx_Oracle disconnect detection, used
|
||
by pre_ping and other features, where an error could be raised
|
||
as DatabaseError which includes a numeric error code; previously
|
||
we weren’t checking in this case for a disconnect code.
|
||
References: #4182
|
||
* misc
|
||
+ [bug] [pool] Fixed a fairly serious connection pool bug where a
|
||
connection that is acquired after being refreshed as a result of
|
||
a user-defined DisconnectionError or due to the 1.2-released
|
||
“pre_ping” feature would not be correctly reset if the
|
||
connection were returned to the pool by weakref cleanup
|
||
(e.g. the front-facing object is garbage collected); the weakref
|
||
would still refer to the previously invalidated DBAPI connection
|
||
which would have the reset operation erroneously called upon it
|
||
instead. This would lead to stack traces in the logs and a
|
||
connection being checked into the pool without being reset,
|
||
which can cause locking issues. This change is also backported
|
||
to: 1.1.16 References: #4184
|
||
+ [bug] [tests] A test added in 1.2 thought to confirm a Python
|
||
2.7 behavior turns out to be confirming the behavior only as of
|
||
Python 2.7.8. Python bug #8743 still impacts set comparison in
|
||
Python 2.7.7 and earlier, so the test in question involving
|
||
AssociationSet no longer runs for these older Python 2.7
|
||
versions. References: #3265
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Jan 28 18:53:04 UTC 2018 - arun@gmx.de
|
||
|
||
- update to version 1.2.2:
|
||
* orm
|
||
+ [orm] [bug] Fixed 1.2 regression regarding new bulk_replace
|
||
event where a backref would fail to remove an object from the
|
||
previous owner when a bulk-assignment assigned the object to a
|
||
new owner. References: #4171
|
||
* mysql
|
||
+ [mysql] [bug] Added more MySQL 8.0 reserved words to the MySQL
|
||
dialect for quoting purposes. Pull request courtesy Riccardo
|
||
Magliocchetti.
|
||
* mssql
|
||
+ [mssql] [bug] Added ODBC error code 10054 to the list of error
|
||
codes that count as a disconnect for ODBC / MSSQL server.
|
||
References: #4164
|
||
* oracle
|
||
+ [oracle] [bug] The cx_Oracle dialect now calls setinputsizes()
|
||
with cx_Oracle.NCHAR unconditionally when the NVARCHAR2
|
||
datatype, in SQLAlchemy corresponding to sqltypes.Unicode(), is
|
||
in use. Per cx_Oracle’s author this allows the correct
|
||
conversions to occur within the Oracle client regardless of the
|
||
setting for NLS_NCHAR_CHARACTERSET. References: #4163
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Jan 17 04:05:43 UTC 2018 - arun@gmx.de
|
||
|
||
- update to version 1.2.1:
|
||
* orm
|
||
+ [orm] [bug] Fixed bug where an object that is expunged during a
|
||
rollback of a nested or subtransaction which also had its
|
||
primary key mutated would not be correctly removed from the
|
||
session, causing subsequent issues in using the session.
|
||
+ [orm] [bug] Fixed regression where pickle format of a Load /
|
||
_UnboundLoad object (e.g. loader options) changed and
|
||
__setstate__() was raising an UnboundLocalError for an object
|
||
received from the legacy format, even though an attempt was made
|
||
to do so. tests are now added to ensure this works.
|
||
+ [orm] [bug] Fixed regression caused by new lazyload caching
|
||
scheme in #3954 where a query that makes use of loader options
|
||
with of_type would cause lazy loads of unrelated paths to fail
|
||
with a TypeError.
|
||
+ [orm] [bug] Fixed bug in new “selectin” relationship loader
|
||
where the loader could try to load a non-existent relationship
|
||
when loading a collection of polymorphic objects, where only
|
||
some of the mappers include that relationship, typically when
|
||
PropComparator.of_type() is being used.
|
||
* sql
|
||
+ [sql] [bug] Fixed bug in Insert.values() where using the
|
||
“multi-values” format in combination with Column objects as keys
|
||
rather than strings would fail. Pull request courtesy Aubrey
|
||
Stark-Toller.
|
||
* mssql
|
||
+ [mssql] [bug] Fixed regression in 1.2 where newly repaired
|
||
quoting of collation names in #3785 breaks SQL Server, which
|
||
explicitly does not understand a quoted collation name. Whether
|
||
or not mixed-case collation names are quoted or not is now
|
||
deferred down to a dialect-level decision so that each dialect
|
||
can prepare these identifiers directly.
|
||
* oracle
|
||
+ [oracle] [bug] Fixed regression where the removal of most
|
||
setinputsizes rules from cx_Oracle dialect impacted the
|
||
TIMESTAMP datatype’s ability to retrieve fractional seconds.
|
||
+ [oracle] [bug] Fixed regression in Oracle imports where a
|
||
missing comma caused an undefined symbol to be present. Pull
|
||
request courtesy Miroslav Shubernetskiy.
|
||
* misc
|
||
+ [bug] [ext] Fixed regression in association proxy due to #3769
|
||
(allow for chained any() / has()) where contains() against an
|
||
association proxy chained in the form (o2m relationship,
|
||
associationproxy(m2o relationship, m2o relationship)) would
|
||
raise an error regarding the re-application of contains() on the
|
||
final link of the chain.
|
||
+ [bug] [tests] Removed an oracle-specific requirements rule from
|
||
the public test suite that was interfering with third party
|
||
dialect suites.
|
||
+ [bug] [tests] Added a new exclusion rule
|
||
group_by_complex_expression which disables tests that use “GROUP
|
||
BY <expr>”, which seems to be not viable for at least two third
|
||
party dialects.
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Jan 3 03:57:00 UTC 2018 - arun@gmx.de
|
||
|
||
- specfile:
|
||
* updated test requirements
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Dec 31 05:58:02 UTC 2017 - arun@gmx.de
|
||
|
||
- update to version 1.2.0:
|
||
* See https://docs.sqlalchemy.org/en/latest/changelog/changelog_12.html
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Sep 25 16:11:55 UTC 2017 - arun@gmx.de
|
||
|
||
- update to version 1.1.14:
|
||
* orm
|
||
+ [orm] [bug] Fixed bug in Session.merge() following along similar
|
||
lines as that of #4030, where an internal check for a target
|
||
object in the identity map could lead to an error if it were to
|
||
be garbage collected immediately before the merge routine
|
||
actually retrieves the object. References: #4069
|
||
+ [orm] [bug] Fixed bug where an undefer_group() option would not
|
||
be recognized if it extended from a relationship that was
|
||
loading using joined eager loading. Additionally, as the bug led
|
||
to excess work being performed, Python function call counts are
|
||
also improved by 20% within the initial calculation of result
|
||
set columns, complementing the joined eager load improvements of
|
||
#3915. References: #4048
|
||
+ [orm] [bug] Fixed race condition in ORM identity map which would
|
||
cause objects to be inappropriately removed during a load
|
||
operation, causing duplicate object identities to occur,
|
||
particularly under joined eager loading which involves
|
||
deduplication of objects. The issue is specific to garbage
|
||
collection of weak references and is observed only under the
|
||
Pypy interpreter. References: #4068
|
||
+ [orm] [bug] Fixed bug in Session.merge() where objects in a
|
||
collection that had the primary key attribute set to None for a
|
||
key that is typically autoincrementing would be considered to be
|
||
a database-persisted key for part of the internal deduplication
|
||
process, causing only one object to actually be inserted in the
|
||
database. References: #4056
|
||
+ [orm] [bug] An InvalidRequestError is raised when a synonym() is
|
||
used against an attribute that is not against a MapperProperty,
|
||
such as an association proxy. Previously, a recursion overflow
|
||
would occur trying to locate non-existent attributes. References: #4067
|
||
* sql
|
||
+ [sql] [bug] Altered the range specification for window functions
|
||
to allow for two of the same PRECEDING or FOLLOWING keywords in
|
||
a range by allowing for the left side of the range to be
|
||
positive and for the right to be negative, e.g. (1, 3) is “1
|
||
FOLLOWING AND 3 FOLLOWING”. References: #4053
|
||
|
||
- changes from version 1.1.13:
|
||
* oracle
|
||
+ [oracle] [bug] [py2k] [performance] Fixed performance regression
|
||
caused by the fix for #3937 where cx_Oracle as of version 5.3
|
||
dropped the .UNICODE symbol from its namespace, which was
|
||
interpreted as cx_Oracle’s “WITH_UNICODE” mode being turned on
|
||
unconditionally, which invokes functions on the SQLAlchemy side
|
||
which convert all strings to unicode unconditionally and causing
|
||
a performance impact. In fact, per cx_Oracle’s author the
|
||
“WITH_UNICODE” mode has been removed entirely as of 5.1, so the
|
||
expensive unicode conversion functions are no longer necessary
|
||
and are disabled if cx_Oracle 5.1 or greater is detected under
|
||
Python 2. The warning against “WITH_UNICODE” mode that was
|
||
removed under #3937 is also restored.
|
||
This change is also backported to: 1.0.19
|
||
References: #4035
|
||
|
||
-------------------------------------------------------------------
|
||
Tue Aug 8 19:39:50 UTC 2017 - tbechtold@suse.com
|
||
|
||
- update to 1.1.12:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.12
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Jul 7 18:06:52 UTC 2017 - tbechtold@suse.com
|
||
|
||
- Update to 1.1.11:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.11
|
||
- Update to 1.1.10:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.10
|
||
|
||
-------------------------------------------------------------------
|
||
Sat May 6 03:31:54 UTC 2017 - toddrme2178@gmail.com
|
||
|
||
- Don't provide python2-sqlalchemy, singlespec packages should use
|
||
correct name.
|
||
|
||
-------------------------------------------------------------------
|
||
Mon May 1 18:49:28 UTC 2017 - toddrme2178@gmail.com
|
||
|
||
- Add literal python-sqlalchemy provides.
|
||
|
||
-------------------------------------------------------------------
|
||
Tue Apr 18 16:07:16 UTC 2017 - toddrme2178@gmail.com
|
||
|
||
- Update to 1.1.9:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.9
|
||
- Update to 1.1.8:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.8
|
||
- Update to 1.1.7:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.7
|
||
- Update to 1.1.6:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.6
|
||
- Update to 1.1.5:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.5
|
||
- Update to 1.1.4:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.4
|
||
- Update to 1.1.3:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.3
|
||
- Update to 1.1.2:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.2
|
||
- Update to 1.1.1:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.1
|
||
- Update to 1.1.0:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_11.html#change-1.1.0
|
||
- Update to 1.0.18:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_10.html#change-1.0.18
|
||
- Update to 1.0.17:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_10.html#change-1.0.17
|
||
- Update to 1.0.16:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_10.html#change-1.0.16
|
||
- Implement single-spec version.
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Sep 15 23:15:10 UTC 2016 - toddrme2178@gmail.com
|
||
|
||
- Update to 1.0.15:
|
||
* See http://docs.sqlalchemy.org/en/latest/changelog/changelog_10.html#change-1.0.15
|
||
http://docs.sqlalchemy.org/en/latest/changelog/changelog_10.html#change-1.0.14
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Jun 6 11:51:07 UTC 2016 - dmueller@suse.com
|
||
|
||
- fix source url
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Jun 3 15:55:53 UTC 2016 - tbechtold@suse.com
|
||
|
||
- update to 1.0.13:
|
||
* see http://docs.sqlalchemy.org/en/latest/changelog/changelog_10.html#change-1.0.12
|
||
and http://docs.sqlalchemy.org/en/latest/changelog/changelog_10.html#change-1.0.13
|
||
Remove 0001-fix-sqlite3.10.0-test.patch. Applied upstream.
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Feb 11 12:33:58 UTC 2016 - aplanas@suse.com
|
||
|
||
- Add 0001-fix-sqlite3.10.0-test.patch
|
||
Backport fix after SQLite3.10 upgrade
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Jan 11 09:35:59 UTC 2016 - bwiedemann@suse.com
|
||
|
||
- update to 1.0.11:
|
||
* see http://docs.sqlalchemy.org/en/latest/changelog/changelog_10.html#change-1.0.11
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Oct 4 09:32:44 UTC 2015 - tbechtold@suse.com
|
||
|
||
- update to 1.0.8:
|
||
* see http://docs.sqlalchemy.org/en/latest/changelog/changelog_10.html#change-1.0.8
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Jun 15 17:19:19 UTC 2015 - bruno@ioda-net.ch
|
||
|
||
- update to version 1.0.5:
|
||
* see http://docs.sqlalchemy.org/en/latest/changelog/changelog_10.html#change-1.0.5
|
||
|
||
-------------------------------------------------------------------
|
||
Sun May 24 08:14:57 UTC 2015 - bruno@ioda-net.ch
|
||
|
||
- update to 1.0.4:
|
||
+ see http://docs.sqlalchemy.org/en/latest/changelog/changelog_10.html#change-1.0.4
|
||
+ see http://docs.sqlalchemy.org/en/latest/changelog/migration_10.html
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Apr 22 12:46:32 UTC 2015 - tbechtold@suse.com
|
||
|
||
- update to 0.9.9:
|
||
+ See http://docs.sqlalchemy.org/en/latest/changelog/changelog_09.html#change-0.9.9
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Jan 8 13:34:04 UTC 2015 - tbechtold@suse.com
|
||
|
||
- Update to version 0.9.8:
|
||
+ See http://docs.sqlalchemy.org/en/latest/changelog/changelog_09.html#change-0.9.8
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Sep 12 07:58:16 UTC 2014 - dmueller@suse.com
|
||
|
||
- update to 0.9.7:
|
||
+ See http://docs.sqlalchemy.org/en/latest/changelog/changelog_09.html#change-0.9.7
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Jul 2 06:04:00 UTC 2014 - nevion@gmail.com
|
||
|
||
-update to 0.9.6:
|
||
+ See http://docs.sqlalchemy.org/en/rel_0_9/changelog/changelog_09.html#change-0.9.6
|
||
-Remove obsolete sqlalchemy-0.7-setup_test.patch
|
||
-Add python-pytest dependency
|
||
|
||
-------------------------------------------------------------------
|
||
Tue Apr 8 09:11:18 UTC 2014 - dmueller@suse.com
|
||
|
||
- update to 0.8.6:
|
||
+ See http://docs.sqlalchemy.org/en/rel_0_9/changelog/changelog_08.html#change-0.8.6
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Oct 30 16:27:24 UTC 2013 - speilicke@suse.com
|
||
|
||
- Update to version 0.8.3:
|
||
+ See http://docs.sqlalchemy.org/en/latest/changelog/changelog_08.html#change-0.8.3
|
||
- Drop outdated patches
|
||
+ SQLAlchemy-0.7.10-SLES-drop-failing-tests.patch
|
||
+ sqlalchemy-0.7-logging.patch
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Oct 24 11:15:08 UTC 2013 - speilicke@suse.com
|
||
|
||
- Require python-setuptools instead of distribute (upstreams merged)
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Aug 1 13:49:51 UTC 2013 - speilicke@suse.com
|
||
|
||
- Add SQLAlchemy-0.7.10-SLES-drop-failing-tests.patch: Cheat with
|
||
dropping tests to fix testsuite on SLE-11
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Jul 22 12:45:58 UTC 2013 - berendt@b1-systems.de
|
||
|
||
- fixing build requirement from python-sqlite to python-pysqlite
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Jul 15 20:05:02 UTC 2013 - hpj@urpla.net
|
||
|
||
- apply patch to fix TypeError, when running python setup.py test
|
||
|
||
-------------------------------------------------------------------
|
||
Sun Jul 14 22:20:29 UTC 2013 - hpj@urpla.net
|
||
|
||
- add python-sqlite build dep for the test rig
|
||
- apply a patch, that fixes TB of the test rig
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Mar 8 08:14:13 UTC 2013 - lars@linux-schulserver.de
|
||
|
||
- update to 0.7.10:
|
||
* orm
|
||
+ [bug] Fixed Session accounting bug whereby replacing
|
||
a deleted object in the identity map with another
|
||
object of the same primary key would raise a
|
||
"conflicting state" error on rollback(),
|
||
if the replaced primary key were established either
|
||
via non-unitofwork-established INSERT statement
|
||
or by primary key switch of another instance.
|
||
[ticket:2583]
|
||
* oracle
|
||
+ [bug] changed the list of cx_oracle types that are
|
||
excluded from the setinputsizes() step to only include
|
||
STRING and UNICODE; CLOB and NCLOB are removed. This
|
||
is to work around cx_oracle behavior which is broken
|
||
for the executemany() call. In 0.8, this same change
|
||
is applied however it is also configurable via the
|
||
exclude_setinputsizes argument. [ticket:2561]
|
||
* mysql
|
||
+ [feature] Added "raise_on_warnings" flag to OurSQL
|
||
dialect. [ticket:2523]
|
||
+ [feature] Added "read_timeout" flag to MySQLdb
|
||
dialect. [ticket:2554]
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Jan 2 18:01:09 UTC 2013 - toddrme2178@gmail.com
|
||
|
||
- Fix building on SLES
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Dec 19 15:48:13 UTC 2012 - saschpe@suse.de
|
||
|
||
- The doc package is noarch
|
||
|
||
-------------------------------------------------------------------
|
||
Fri Nov 2 17:53:22 UTC 2012 - termim@gmail.com
|
||
|
||
- do not require python-pysqlite package.
|
||
- update to 0.7.9:
|
||
|
||
*orm
|
||
|
||
- [bug] Fixed bug mostly local to new AbstractConcreteBase helper
|
||
where the "type" attribute from the superclass would not be overridden
|
||
on the subclass to produce the "reserved for base" error message,
|
||
instead placing a do-nothing attribute there. This was inconsistent
|
||
vs. using ConcreteBase as well as all the behavior of classical
|
||
concrete mappings, where the "type" column from the polymorphic base
|
||
would be explicitly disabled on subclasses, unless overridden
|
||
explicitly.
|
||
|
||
- [bug] A warning is emitted when lazy='dynamic' is combined with
|
||
uselist=False. This is an exception raise in 0.8.
|
||
|
||
- [bug] Fixed bug whereby user error in related-object assignment could
|
||
cause recursion overflow if the assignment triggered a backref of the
|
||
same name as a bi-directional attribute on the incorrect class to the
|
||
same target. An informative error is raised now.
|
||
|
||
- [bug] Fixed bug where incorrect type information would be passed when
|
||
the ORM would bind the "version" column, when using the "version"
|
||
feature. Tests courtesy Daniel Miller. [ticket:2539]
|
||
|
||
- [bug] Extra logic has been added to the "flush" that occurs within
|
||
Session.commit(), such that the extra state added by an after_flush()
|
||
or after_flush_postexec() hook is also flushed in a subsequent flush,
|
||
before the "commit" completes. Subsequent calls to flush() will
|
||
continue until the after_flush hooks stop adding new state. An
|
||
"overflow" counter of 100 is also in place, in the event of a broken
|
||
after_flush() hook adding new content each time. [ticket:2566]
|
||
|
||
*engine
|
||
|
||
- [feature] Dramatic improvement in memory usage of the event system;
|
||
instance-level collections are no longer created for a particular type of
|
||
event until instance-level listeners are established for that
|
||
event. [ticket:2516]
|
||
|
||
- [bug] Fixed bug whereby a disconnect detect + dispose that occurs when
|
||
the QueuePool has threads waiting for connections would leave those
|
||
threads waiting for the duration of the timeout on the old pool (or
|
||
indefinitely if timeout was disabled). The fix now notifies those
|
||
waiters with a special exception case and has them move onto the new
|
||
pool. [ticket:2522]
|
||
|
||
- [bug] Added gaerdbms import to mysql/__init__.py, the absense of which
|
||
was preventing the new GAE dialect from being loaded. [ticket:2529]
|
||
|
||
- [bug] Fixed cextension bug whereby the "ambiguous column error" would
|
||
fail to function properly if the given index were a Column object and
|
||
not a string. Note there are still some column-targeting issues here
|
||
which are fixed in 0.8. [ticket:2553]
|
||
|
||
- [bug] Fixed the repr() of Enum to include the "name" and "native_enum"
|
||
flags. Helps Alembic autogenerate.
|
||
|
||
*sql
|
||
|
||
- [bug] Fixed the DropIndex construct to support an Index associated with
|
||
a Table in a remote schema. [ticket:2571]
|
||
|
||
- [bug] Fixed bug in over() construct whereby passing an empty list for
|
||
either partition_by or order_by, as opposed to None, would fail to
|
||
generate correctly. Courtesy Gunnlaugur Þór Briem. [ticket:2574]
|
||
|
||
- [bug] Fixed CTE bug whereby positional bound parameters present in the
|
||
CTEs themselves would corrupt the overall ordering of bound
|
||
parameters. This primarily affected SQL Server as the platform with
|
||
positional binds + CTE support. [ticket:2521]
|
||
|
||
- [bug] Fixed more un-intuitivenesses in CTEs which prevented referring
|
||
to a CTE in a union of itself without it being aliased. CTEs now render
|
||
uniquely on name, rendering the outermost CTE of a given name only -
|
||
all other references are rendered just as the name. This even includes
|
||
other CTE/SELECTs that refer to different versions of the same CTE
|
||
object, such as a SELECT or a UNION ALL of that SELECT. We are somewhat
|
||
loosening the usual link between object identity and lexical identity
|
||
in this case. A true name conflict between two unrelated CTEs now
|
||
raises an error.
|
||
|
||
- [bug] quoting is applied to the column names inside the WITH RECURSIVE
|
||
clause of a common table expression according to the quoting rules for
|
||
the originating Column. [ticket:2512]
|
||
|
||
- [bug] Fixed regression introduced in 0.7.6 whereby the FROM list of a
|
||
SELECT statement could be incorrect in certain "clone+replace"
|
||
scenarios. [ticket:2518]
|
||
|
||
- [bug] Fixed bug whereby usage of a UNION or similar inside of an
|
||
embedded subquery would interfere with result-column targeting, in the
|
||
case that a result-column had the same ultimate name as a name inside
|
||
the embedded UNION. [ticket:2552]
|
||
|
||
- [bug] Fixed a regression since 0.6 regarding result-row targeting. It
|
||
should be possible to use a select() statement with string based
|
||
columns in it, that is select(['id', 'name']).select_from('mytable'),
|
||
and have this statement be targetable by Column objects with those
|
||
names; this is the mechanism by which
|
||
query(MyClass).from_statement(some_statement) works. At some point the
|
||
specific case of using select(['id']), which is equivalent to
|
||
select([literal_column('id')]), stopped working here, so this has been
|
||
re-instated and of course tested. [ticket:2558]
|
||
|
||
- [bug] Added missing operators is_(), isnot() to the ColumnOperators
|
||
base, so that these long-available operators are present as methods
|
||
like all the other operators. [ticket:2544]
|
||
|
||
*postgresql
|
||
|
||
- [bug] Columns in reflected primary key constraint are now returned in
|
||
the order in which the constraint itself defines them, rather than how
|
||
the table orders them. Courtesy Gunnlaugur Þór Briem.. [ticket:2531]
|
||
|
||
- [bug] Added 'terminating connection' to the list of messages we use to
|
||
detect a disconnect with PG, which appears to be present in some
|
||
versions when the server is restarted. [ticket:2570]
|
||
|
||
*mysql
|
||
|
||
- [bug] Updated mysqlconnector interface to use updated "client flag" and
|
||
"charset" APIs, courtesy David McNelis.
|
||
|
||
*sqlite
|
||
|
||
- [feature] Added support for the localtimestamp() SQL function
|
||
implemented in SQLite, courtesy Richard Mitchell.
|
||
|
||
- [bug] Adjusted a very old bugfix which attempted to work around a
|
||
SQLite issue that itself was "fixed" as of sqlite 3.6.14, regarding
|
||
quotes surrounding a table name when using the "foreign_key_list"
|
||
pragma. The fix has been adjusted to not interfere with quotes that are
|
||
actually in the name of a column or table, to as much a degree as
|
||
possible; sqlite still doesn't return the correct result for
|
||
foreign_key_list() if the target table actually has quotes surrounding
|
||
its name, as part of its name (i.e. """mytable"""). [ticket:2568]
|
||
|
||
- [bug] Adjusted column default reflection code to convert non-string
|
||
values to string, to accommodate old SQLite versions that don't deliver
|
||
default info as a string. [ticket:2265]
|
||
|
||
*mssql
|
||
|
||
- [bug] Fixed compiler bug whereby using a correlated subquery within an
|
||
ORDER BY would fail to render correctly if the stament also used
|
||
LIMIT/OFFSET, due to mis-rendering within the ROW_NUMBER() OVER
|
||
clause. Fix courtesy sayap [ticket:2538]
|
||
|
||
- [bug] Fixed compiler bug whereby a given select() would be modified if
|
||
it had an "offset" attribute, causing the construct to not compile
|
||
correctly a second time. [ticket:2545]
|
||
|
||
- [bug] Fixed bug where reflection of primary key constraint would double
|
||
up columns if the same constraint/table existed in multiple schemas.
|
||
|
||
- update to 0.7.8:
|
||
|
||
*orm
|
||
|
||
- [feature] The 'objects' argument to flush() is no longer deprecated, as
|
||
some valid use cases have been identified.
|
||
|
||
- [bug] Fixed bug whereby subqueryload() from a polymorphic mapping to a
|
||
target would incur a new invocation of the query for each distinct
|
||
class encountered in the polymorphic result. [ticket:2480]
|
||
|
||
- [bug] Fixed bug in declarative whereby the precedence of columns in a
|
||
joined-table, composite column (typically for id) would fail to be
|
||
correct if the columns contained names distinct from their attribute
|
||
names. This would cause things like primaryjoin conditions made against
|
||
the entity attributes to be incorrect. Related to as this was supposed
|
||
to be part of that, this is. [ticket:2491, 1892]
|
||
|
||
- [bug] Fixed identity_key() function which was not accepting a scalar
|
||
argument for the identity. . [ticket:2508]
|
||
|
||
- [bug] Fixed bug whereby populate_existing option would not propagate to
|
||
subquery eager loaders. . [ticket:2497]
|
||
|
||
*engine
|
||
|
||
- [bug] Fixed memory leak in C version of result proxy whereby DBAPIs
|
||
which don't deliver pure Python tuples for result rows would fail to
|
||
decrement refcounts correctly. The most prominently affected DBAPI is
|
||
pyodbc. [ticket:2489]
|
||
|
||
- [bug] Fixed bug affecting Py3K whereby string positional parameters
|
||
passed to engine/connection execute() would fail to be interpreted
|
||
correctly, due to __iter__ being present on Py3K string.. [ticket:2503]
|
||
|
||
*sql
|
||
|
||
- [bug] added BIGINT to types.__all__, BIGINT, BINARY, VARBINARY to
|
||
sqlalchemy module namespace, plus test to ensure this breakage doesn't
|
||
occur again. [ticket:2499]
|
||
|
||
- [bug] Repaired common table expression rendering to function correctly
|
||
when the SELECT statement contains UNION or other compound expressions,
|
||
courtesy btbuilder. [ticket:2490]
|
||
|
||
- [bug] Fixed bug whereby append_column() wouldn't function correctly on
|
||
a cloned select() construct, courtesy Gunnlaugur Þór
|
||
Briem. [ticket:2482]
|
||
|
||
*postgresql
|
||
|
||
- [bug] removed unnecessary table clause when reflecting enums,. Courtesy
|
||
Gunnlaugur Þór Briem. [ticket:2510]
|
||
|
||
*mysql
|
||
|
||
- [feature] Added a new dialect for Google App Engine. Courtesy Richie
|
||
Foreman. [ticket:2484]
|
||
|
||
*oracle
|
||
|
||
- [bug] Added ROWID to oracle.*. [ticket:2483]
|
||
|
||
-------------------------------------------------------------------
|
||
Wed May 23 06:44:12 UTC 2012 - highwaystar.ru@gmail.com
|
||
|
||
- python3 package added
|
||
- removed BuildRequires update-desktop-files, because there is no
|
||
desktop files in package
|
||
- minor spec improvement
|
||
|
||
-------------------------------------------------------------------
|
||
Sun May 6 12:22:59 UTC 2012 - lars@linux-schulserver.de
|
||
|
||
- update to 0.7.7:
|
||
* orm
|
||
- [bug] Fixed issue in unit of work whereby setting a non-None
|
||
self-referential many-to-one relationship to None would fail
|
||
to persist the change if the former value was not already loaded.
|
||
[ticket:2477].
|
||
|
||
- [feature] Added prefix_with() method to Query, calls upon
|
||
select().prefix_with() to allow placement of MySQL SELECT
|
||
directives in statements. Courtesy Diana Clarke [ticket:2443]
|
||
|
||
- [bug] Fixed bug in 0.7.6 introduced by [ticket:2409] whereby
|
||
column_mapped_collection used against columns that were mapped as
|
||
joins or other indirect selectables would fail to function.
|
||
|
||
- [feature] Added new flag to @validates include_removes. When True,
|
||
collection remove and attribute del events will also be sent to
|
||
the validation function, which accepts an additional argument
|
||
"is_remove" when this flag is used.
|
||
|
||
- [bug] Fixed bug whereby polymorphic_on column that's not otherwise
|
||
mapped on the class would be incorrectly included in a merge()
|
||
operation, raising an error. [ticket:2449]
|
||
|
||
- [bug] Fixed bug in expression annotation mechanics which could
|
||
lead to incorrect rendering of SELECT statements with aliases
|
||
and joins, particularly when using column_property(). [ticket:2453]
|
||
|
||
- [bug] Fixed bug which would prevent OrderingList from being
|
||
pickleable [ticket:2454]. Courtesy Jeff Dairiki
|
||
|
||
- [bug] Fixed bug in relationship comparisons whereby calling
|
||
unimplemented methods like SomeClass.somerelationship.like()
|
||
would produce a recursion overflow, instead of NotImplementedError.
|
||
|
||
* sql
|
||
- [bug] Removed warning when Index is created with no columns;
|
||
while this might not be what the user intended, it is a valid use case
|
||
as an Index could be a placeholder for just an index of a certain name.
|
||
|
||
- [feature] Added new connection event dbapi_error(). Is called for
|
||
all DBAPI-level errors passing the original DBAPI exception before
|
||
SQLAlchemy modifies the state of the cursor. "with engine.begin()",
|
||
the newly acquired Connection is closed explicitly before propagating
|
||
the exception onward normally.
|
||
|
||
- [bug] Add BINARY, VARBINARY to types.__all__, [ticket:2474]
|
||
|
||
* mssql
|
||
- [feature] Added interim create_engine flag supports_unicode_binds
|
||
to PyODBC dialect, to force whether or not the dialect passes
|
||
Python unicode literals to PyODBC or not.
|
||
|
||
- [bug] Repaired the use_scope_identity create_engine() flag when
|
||
using the pyodbc dialect. Previously this flag would be ignored if
|
||
set to False. When set to False, you'll get "SELECT @@identity"
|
||
after each INSERT to get at the last inserted ID, for those tables
|
||
which have "implicit_returning" set to False.
|
||
|
||
- [bug] UPDATE..FROM syntax with SQL Server requires that the updated
|
||
table be present in the FROM clause when an alias of that table is
|
||
also present in the FROM clause. The updated table is now always present
|
||
in the FROM, when FROM is present in the first place. Courtesy sayap.
|
||
[ticket:2468]
|
||
|
||
* postgresql
|
||
- [feature] Added new for_update/with_lockmode() options for Postgresql:
|
||
for_update="read"/ with_lockmode("read"), for_update="read_nowait"/
|
||
with_lockmode("read_nowait"). These emit "FOR SHARE" and "FOR SHARE
|
||
NOWAIT", respectively. Courtesy Diana Clarke [ticket:2445]
|
||
|
||
- [bug] removed unnecessary table clause when reflecting domains, [ticket:2473]
|
||
|
||
* mysql
|
||
- [bug] Fixed bug whereby column name inside of "KEY" clause for autoincrement
|
||
composite column with InnoDB would double quote a name that's a reserved
|
||
word. Courtesy Jeff Dairiki. [ticket:2460]
|
||
|
||
- [bug] Fixed bug whereby get_view_names() for "information_schema" schema
|
||
would fail to retrieve views marked as "SYSTEM VIEW". courtesy Matthew Turland.
|
||
|
||
- [bug] Fixed bug whereby if cast() is used on a SQL expression whose type
|
||
is not supported by cast() and therefore CAST isn't rendered by the
|
||
dialect, the order of evaluation could change if the casted expression
|
||
required that it be grouped; grouping is now applied to those expressions.
|
||
|
||
* sqlite
|
||
- [feature] Added SQLite execution option "sqlite_raw_colnames=True", will
|
||
bypass attempts to remove "." from column names returned by SQLite
|
||
cursor.description. [ticket:2475]
|
||
|
||
-------------------------------------------------------------------
|
||
Mon Apr 30 09:13:02 UTC 2012 - cfarrell@suse.com
|
||
|
||
- Update to 0.7.6
|
||
* orm
|
||
- [bug] Fixed event registration bug
|
||
which would primarily show up as
|
||
events not being registered with
|
||
sessionmaker() instances created
|
||
after the event was associated
|
||
with the Session class. [ticket:2424]
|
||
|
||
- [bug] Fixed bug whereby a primaryjoin
|
||
condition with a "literal" in it would
|
||
raise an error on compile with certain
|
||
kinds of deeply nested expressions
|
||
which also needed to render the same
|
||
bound parameter name more than once.
|
||
[ticket:2425]
|
||
|
||
- [feature] Added "no_autoflush" context
|
||
manager to Session, used with with:
|
||
will temporarily disable autoflush.
|
||
|
||
- [feature] Added cte() method to Query,
|
||
invokes common table expression support
|
||
from the Core (see below). [ticket:1859]
|
||
|
||
- [bug] Removed the check for number of
|
||
rows affected when doing a multi-delete
|
||
against mapped objects. If an ON DELETE
|
||
CASCADE exists between two rows, we can't
|
||
get an accurate rowcount from the DBAPI;
|
||
this particular count is not supported
|
||
on most DBAPIs in any case, MySQLdb
|
||
is the notable case where it is.
|
||
[ticket:2403]
|
||
|
||
- [bug] Fixed bug whereby objects using
|
||
attribute_mapped_collection or
|
||
column_mapped_collection could not be
|
||
pickled. [ticket:2409]
|
||
|
||
- [bug] Fixed bug whereby MappedCollection
|
||
would not get the appropriate collection
|
||
instrumentation if it were only used
|
||
in a custom subclass that used
|
||
@collection.internally_instrumented.
|
||
[ticket:2406]
|
||
|
||
- [bug] Fixed bug whereby SQL adaption mechanics
|
||
would fail in a very nested scenario involving
|
||
joined-inheritance, joinedload(), limit(), and a
|
||
derived function in the columns clause.
|
||
[ticket:2419]
|
||
|
||
- [bug] Fixed the repr() for CascadeOptions to
|
||
include refresh-expire. Also reworked
|
||
CascadeOptions to be a <frozenset>.
|
||
[ticket:2417]
|
||
|
||
- [feature] Added the ability to query for
|
||
Table-bound column names when using
|
||
query(sometable).filter_by(colname=value).
|
||
[ticket:2400]
|
||
|
||
- [bug] Improved the "declarative reflection"
|
||
example to support single-table inheritance,
|
||
multiple calls to prepare(), tables that
|
||
are present in alternate schemas,
|
||
establishing only a subset of classes
|
||
as reflected.
|
||
|
||
- [bug] Scaled back the test applied within
|
||
flush() to check for UPDATE against partially
|
||
NULL PK within one table to only actually
|
||
happen if there's really an UPDATE to occur.
|
||
[ticket:2390]
|
||
|
||
- [bug] Fixed bug whereby if a method name
|
||
conflicted with a column name, a
|
||
TypeError would be raised when the mapper
|
||
tried to inspect the __get__() method
|
||
on the method object. [ticket:2352]
|
||
|
||
* sql
|
||
- [bug] Fixed memory leak in core which would
|
||
occur when C extensions were used with
|
||
particular types of result fetches,
|
||
in particular when orm query.count()
|
||
were called. [ticket:2427]
|
||
|
||
- [bug] Fixed issue whereby attribute-based
|
||
column access on a row would raise
|
||
AttributeError with non-C version,
|
||
NoSuchColumnError with C version. Now
|
||
raises AttributeError in both cases.
|
||
[ticket:2398]
|
||
|
||
- [feature] Added support for SQL standard
|
||
common table expressions (CTE), allowing
|
||
SELECT objects as the CTE source (DML
|
||
not yet supported). This is invoked via
|
||
the cte() method on any select() construct.
|
||
[ticket:1859]
|
||
|
||
- [bug] Added support for using the .key
|
||
of a Column as a string identifier in a
|
||
result set row. The .key is currently
|
||
listed as an "alternate" name for a column,
|
||
and is superseded by the name of a column
|
||
which has that key value as its regular name.
|
||
For the next major release
|
||
of SQLAlchemy we may reverse this precedence
|
||
so that .key takes precedence, but this
|
||
is not decided on yet. [ticket:2392]
|
||
|
||
- [bug] A warning is emitted when a not-present
|
||
column is stated in the values() clause
|
||
of an insert() or update() construct.
|
||
Will move to an exception in 0.8.
|
||
[ticket:2413]
|
||
|
||
- [bug] A significant change to how labeling
|
||
is applied to columns in SELECT statements
|
||
allows "truncated" labels, that is label names
|
||
that are generated in Python which exceed
|
||
the maximum identifier length (note this is
|
||
configurable via label_length on create_engine()),
|
||
to be properly referenced when rendered inside
|
||
of a subquery, as well as to be present
|
||
in a result set row using their original
|
||
in-Python names. [ticket:2396]
|
||
|
||
- [bug] Fixed bug in new "autoload_replace" flag
|
||
which would fail to preserve the primary
|
||
key constraint of the reflected table.
|
||
[ticket:2402]
|
||
|
||
- [bug] Index will raise when arguments passed
|
||
cannot be interpreted as columns or expressions.
|
||
Will warn when Index is created
|
||
with no columns at all. [ticket:2380]
|
||
|
||
* engine
|
||
- [feature] Added "no_parameters=True" execution
|
||
option for connections. If no parameters
|
||
are present, will pass the statement
|
||
as cursor.execute(statement), thereby invoking
|
||
the DBAPIs behavior when no parameter collection
|
||
is present; for psycopg2 and mysql-python, this
|
||
means not interpreting % signs in the string.
|
||
This only occurs with this option, and not
|
||
just if the param list is blank, as otherwise
|
||
this would produce inconsistent behavior
|
||
of SQL expressions that normally escape percent
|
||
signs (and while compiling, can't know ahead of
|
||
time if parameters will be present in
|
||
some cases). [ticket:2407]
|
||
|
||
- [bug] Added execution_options() call to
|
||
MockConnection (i.e., that used with
|
||
strategy="mock") which acts as a pass through
|
||
for arguments.
|
||
|
||
- [feature] Added pool_reset_on_return argument
|
||
to create_engine, allows control over
|
||
"connection return" behavior. Also added
|
||
new arguments 'rollback', 'commit', None
|
||
to pool.reset_on_return to allow more control
|
||
over connection return activity. [ticket:2378]
|
||
|
||
- [feature] Added some decent context managers
|
||
to Engine, Connection:
|
||
|
||
with engine.begin() as conn:
|
||
<work with conn in a transaction>
|
||
|
||
and:
|
||
|
||
with engine.connect() as conn:
|
||
<work with conn>
|
||
|
||
Both close out the connection when done,
|
||
commit or rollback transaction with errors
|
||
on engine.begin().
|
||
|
||
* sqlite
|
||
- [bug] Fixed bug in C extensions whereby
|
||
string format would not be applied to a
|
||
Numeric value returned as integer; this
|
||
affected primarily SQLite which does
|
||
not maintain numeric scale settings.
|
||
[ticket:2432]
|
||
|
||
* mssql
|
||
- [feature] Added support for MSSQL INSERT,
|
||
UPDATE, and DELETE table hints, using
|
||
new with_hint() method on UpdateBase.
|
||
[ticket:2430]
|
||
|
||
* mysql
|
||
- [feature] Added support for MySQL index and
|
||
primary key constraint types
|
||
(i.e. USING) via new mysql_using parameter
|
||
to Index and PrimaryKeyConstraint,
|
||
courtesy Diana Clarke. [ticket:2386]
|
||
|
||
- [feature] Added support for the "isolation_level"
|
||
parameter to all MySQL dialects. Thanks
|
||
to mu_mind for the patch here. [ticket:2394]
|
||
|
||
* oracle
|
||
- [feature] Added a new create_engine() flag
|
||
coerce_to_decimal=False, disables the precision
|
||
numeric handling which can add lots of overhead
|
||
by converting all numeric values to
|
||
Decimal. [ticket:2399]
|
||
|
||
- [bug] Added missing compilation support for
|
||
LONG [ticket:2401]
|
||
|
||
- [bug] Added 'LEVEL' to the list of reserved
|
||
words for Oracle. [ticket:2435]
|
||
|
||
* examples
|
||
- [bug] Altered _params_from_query() function
|
||
in Beaker example to pull bindparams from the
|
||
fully compiled statement, as a quick means
|
||
to get everything including subqueries in the
|
||
columns clause, etc.
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Feb 22 12:36:45 UTC 2012 - saschpe@suse.de
|
||
|
||
- Fixed SLE_11 build by disabling the testsuite for it
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Feb 9 09:39:26 UTC 2012 - rhafer@suse.de
|
||
|
||
- Update to 0.7.5:
|
||
* Fixed issue where modified session state established after a
|
||
failed flush would be committed as part of the subsequent
|
||
transaction that begins automatically after manual call to
|
||
rollback().
|
||
* Improved the API for add_column() such that if the same column
|
||
is added to its own table, an error is not raised and the
|
||
constraints don't get doubled up.
|
||
* Fixed issue where the "required" exception would not be raised
|
||
for bindparam() with required=True, if the statement were given
|
||
no parameters at all.
|
||
* for more details see the CHANGES file.
|
||
|
||
-------------------------------------------------------------------
|
||
Thu Nov 10 10:56:36 UTC 2011 - saschpe@suse.de
|
||
|
||
- Add depenendency on pysqlite
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Sep 21 11:51:17 UTC 2011 - saschpe@suse.de
|
||
|
||
- Update to version 0.7.2:
|
||
* A rework of "replacement traversal"
|
||
* Fixed bug where query.join() + aliased=True
|
||
* Fixed regression from 0.6 where Session.add()
|
||
against an object which contained None
|
||
- See CHANGES for more...
|
||
- Run testsuite
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Jul 20 17:42:11 UTC 2011 - saschpe@gmx.de
|
||
|
||
- Let doc package require base package instead of recommends
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Jul 20 17:23:11 UTC 2011 - saschpe@gmx.de
|
||
|
||
- Dropped unused BuildRequires for fdupes and python-sqlite2
|
||
|
||
-------------------------------------------------------------------
|
||
Wed Jul 20 16:59:39 UTC 2011 - saschpe@gmx.de
|
||
|
||
- Initial version, replaces python-sqlalchemy
|
||
* Much simpler spec file
|
||
* Packaged LICENSE, CHANGES and README files
|