Currently, ``Session.bulk_insert_mappings`` omits NULL values which causes it to break up batches of inserts based on which batches contain NULL and which do not. By adding this flag, the same columns are rendered in the INSERT for all rows allowing them to be batched. The downside is that server-side defaults are omitted. Doctext-author: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: Iec5969304d4bdbf57290b200331bde02254aa3a5 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/243
would still potentially cause persistence conflicts on the next transaction, because the instance would not be checked that it was expired. This fix will resolve a large class of cases that erronously cause the "New instance with identity X conflicts with persistent instance Y" error. fixes #3677
available mapper options. This allows a DELETE to proceed for a joined-table inheritance mapping against the base table only, while allowing for ON DELETE CASCADE to handle deleting the row from the subclass tables. fixes #2349
the same cached starting statement each time. no issue has been observed with the former but it could perhaps have issues w/ versioning or eager_defaults
would not bump a version id counter when in use. The experience here is still a little rough as the original version id is required in the given dictionaries and there's not clean error reporting on that yet. fixes #3610
insert-default holding columns not otherwise included in the SET clause (such as primary key cols) to get rendered into the RETURNING even though this is an UPDATE. - Major fixes to the :paramref:`.Mapper.eager_defaults` flag, this flag would not be honored correctly in the case that multiple UPDATE statements were to be emitted, either as part of a flush or a bulk update operation. Additionally, RETURNING would be emitted unnecessarily within update statements. fixes #3609
statement. This feature is available by passing the :paramref:`~.sqlalchemy.sql.expression.update.preserve_parameter_order` flag either to the core :class:`.Update` construct or alternatively adding it to the :paramref:`.Query.update.update_args` dictionary at the ORM-level, also passing the parameters themselves as a list of 2-tuples. Thanks to Gorka Eguileor for implementation and tests. adapted from pullreq github:200
as versioning isn't needed, fixes test_unitofworkv2->test_update_multi_missing_broken_multi_rowcount
for UPDATE statements in the ORM (e.g. :ref:`feature_updatemany`) would break on Postgresql and other RETURNING backends when using server-side version generation schemes, as the server side value is retrieved via RETURNING which is not supported with executemany. fixes #3556