summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/sql/_typing.py
diff options
context:
space:
mode:
authorMike Bayer <mike_mp@zzzcomputing.com>2022-05-08 22:49:33 -0400
committerMike Bayer <mike_mp@zzzcomputing.com>2022-05-09 09:49:50 -0400
commitd972b0f4ed4cd55c3f8e422816b32e9081168513 (patch)
treebed6eabf2708bf19a8d1024dd73b95672431653c /lib/sqlalchemy/sql/_typing.py
parent47c91d06b56b0a0cf366d3c1f8b6d71a82149e43 (diff)
downloadsqlalchemy-d972b0f4ed4cd55c3f8e422816b32e9081168513.tar.gz
explicitly fetch inserted pk for values(pkcol=None)
Altered the compilation mechanics of the :class:`.Insert` construct such that the "autoincrement primary key" column value will be fetched via ``cursor.lastrowid`` or RETURNING even if present in the parameter set or within the :meth:`.Insert.values` method as a plain bound value, for single-row INSERT statements on specific backends that are known to generate autoincrementing values even when explicit NULL is passed. This restores a behavior that was in the 1.3 series for both the use case of separate parameter set as well as :meth:`.Insert.values`. In 1.4, the parameter set behavior unintentionally changed to no longer do this, but the :meth:`.Insert.values` method would still fetch autoincrement values up until 1.4.21 where :ticket:`6770` changed the behavior yet again again unintentionally as this use case was never covered. The behavior is now defined as "working" to suit the case where databases such as SQLite, MySQL and MariaDB will ignore an explicit NULL primary key value and nonetheless invoke an autoincrement generator. Fixes: #7998 Change-Id: I5d4105a14217945f87fbe9a6f2a3c87f6ef20529
Diffstat (limited to 'lib/sqlalchemy/sql/_typing.py')
0 files changed, 0 insertions, 0 deletions