]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commit
apply literal value resolution to String
authorMike Bayer <mike_mp@zzzcomputing.com>
Mon, 7 Feb 2022 17:08:51 +0000 (12:08 -0500)
committerMike Bayer <mike_mp@zzzcomputing.com>
Mon, 7 Feb 2022 17:13:40 +0000 (12:13 -0500)
commit24de22338522779c5d9e720c4b97dc8609136c29
tree15fcc304a20f81798b1e73afa66ddd368e6d7b31
parent88bc4f2f66cffe82ed039a622027abd54897280a
apply literal value resolution to String

Python string values for which a SQL type is determined from the type of
the value, mainly when using :func:`_sql.literal`, will now apply the
:class:`_types.String` type, rather than the :class:`_types.Unicode`
datatype, for Python string values that test as "ascii only" using Python
``str.isascii()``. If the string is not ``isascii()``, the
:class:`_types.Unicode` datatype will be bound instead, which was used in
all string detection previously. This behavior **only applies to in-place
detection of datatypes when using ``literal()`` or other contexts that have
no existing datatype**, which is not usually the case under normal
:class:`_schema.Column` comparison operations, where the type of the
:class:`_schema.Column` being compared always takes precedence.

Use of the :class:`_types.Unicode` datatype can determine literal string
formatting on backends such as SQL Server, where a literal value (i.e.
using ``literal_binds``) will be rendered as ``N'<value>'`` instead of
``'value'``. For normal bound value handling, the :class:`_types.Unicode`
datatype also may have implications for passing values to the DBAPI, again
in the case of SQL Server, the pyodbc driver supports the use of
:ref:`setinputsizes mode <mssql_pyodbc_setinputsizes>` which will handle
:class:`_types.String` versus :class:`_types.Unicode` differently.

Fixes: #7551
Change-Id: I4f8de63e36532ae8ce4c630ee59211349ce95361
doc/build/changelog/unreleased_20/7551.rst [new file with mode: 0644]
lib/sqlalchemy/sql/sqltypes.py
test/dialect/mssql/test_types.py
test/sql/test_types.py