Accepting request 749101 from devel:languages:python
OBS-URL: https://build.opensuse.org/request/show/749101 OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/python-SQLAlchemy?expand=0&rev=71
This commit is contained in:
Git OBS Bridge
@@ -1,3 +0,0 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:0f0768b5db594517e1f5e1572c73d14cf295140756431270d89496dc13d5e46c
|
||||
size 5967223
|
||||
3
SQLAlchemy-1.3.11.tar.gz
Normal file
3
SQLAlchemy-1.3.11.tar.gz
Normal file
@@ -0,0 +1,3 @@
|
||||
version https://git-lfs.github.com/spec/v1
|
||||
oid sha256:afa5541e9dea8ad0014251bc9d56171ca3d8b130c9627c6cb3681cff30be3f8a
|
||||
size 6007784
|
||||
@@ -1,3 +1,197 @@
|
||||
-------------------------------------------------------------------
|
||||
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>
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
%{?!python_module:%define python_module() python-%{**} python3-%{**}}
|
||||
%define oldpython python
|
||||
Name: python-SQLAlchemy
|
||||
Version: 1.3.10
|
||||
Version: 1.3.11
|
||||
Release: 0
|
||||
Summary: Database Abstraction Library
|
||||
License: MIT
|
||||
@@ -31,6 +31,7 @@ BuildRequires: %{python_module setuptools}
|
||||
BuildRequires: %{pythons}
|
||||
BuildRequires: fdupes
|
||||
BuildRequires: python-rpm-macros
|
||||
Requires: python
|
||||
Provides: python-sqlalchemy = %{version}
|
||||
Obsoletes: python-sqlalchemy < %{version}
|
||||
# SECTION test requirements
|
||||
|
||||
Reference in New Issue
Block a user