diff options
author | Mike Bayer <mike_mp@zzzcomputing.com> | 2022-02-07 12:08:51 -0500 |
---|---|---|
committer | Mike Bayer <mike_mp@zzzcomputing.com> | 2022-02-07 12:13:40 -0500 |
commit | 24de22338522779c5d9e720c4b97dc8609136c29 (patch) | |
tree | 15fcc304a20f81798b1e73afa66ddd368e6d7b31 /lib/sqlalchemy/dialects/sqlite/pysqlite.py | |
parent | 88bc4f2f66cffe82ed039a622027abd54897280a (diff) | |
download | sqlalchemy-24de22338522779c5d9e720c4b97dc8609136c29.tar.gz |
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
Diffstat (limited to 'lib/sqlalchemy/dialects/sqlite/pysqlite.py')
0 files changed, 0 insertions, 0 deletions