as a result of the bugfix for :ticket:`3167`, where attribute and validation events are no longer called within the flush process. The mutable extension was relying upon this behavior in the case where a column level Python-side default were responsible for generating the new value on INSERT or UPDATE, or when a value were fetched from the RETURNING clause for "eager defaults" mode. The new value would not be subject to any event when populated and the mutable extension could not establish proper coercion or history listening. A new event :meth:`.InstanceEvents.refresh_flush` is added which the mutable extension now makes use of for this use case. fixes #3427 - Added new event :meth:`.InstanceEvents.refresh_flush`, invoked when an INSERT or UPDATE level default value fetched via RETURNING or Python-side default is invoked within the flush process. This is to provide a hook that is no longer present as a result of :ticket:`3167`, where attribute and validation events are no longer called within the flush process. - Added a new semi-public method to :class:`.MutableBase` :meth:`.MutableBase._get_listen_keys`. Overriding this method is needed in the case where a :class:`.MutableBase` subclass needs events to propagate for attribute keys other than the key to which the mutable type is associated with, when intercepting the :meth:`.InstanceEvents.refresh` or :meth:`.InstanceEvents.refresh_flush` events. The current example of this is composites using :class:`.MutableComposite`.
sane multi rowcount (e.g. pyodbc) would fail on multirow update. add a test that mocks this breakage into plain dialects
we only call upon the history API fully for primary key columns. We also now skip the whole step of looking at PK columns and using any history at all if no net changes are detected on the object.
``@validates`` would have events triggered within the flush process, when those columns were the targets of a "fetch and populate" operation, such as an autoincremented primary key, a Python side default, or a server-side default "eagerly" fetched via RETURNING. fixes #3167
into more performant executemany() call, similarly to how INSERT statements can be batched; this will be invoked within flush to the degree that subsequent UPDATE statements for the same mapping and table involve the identical columns within the VALUES clause, as well as that no VALUES-level SQL expressions are embedded. - some other inlinings within persistence.py
when we do a get; we return the None as always but we leave the dict blank and the loader callable still in place. The case for this implicit get on a pending object is not super common and there really should be no change in state at all when this operation proceeds. This change is more dramatic as it reverses a behavior SQLA has had since the first release. fixes #3061
fix that is updated more comprehensively in 1.0 via :ticket:`3061`. The fix in :ticket:`3060` unfortunately produces a new issue whereby an eager load of a many-to-one attribute can produce an event that is interpreted into an attribute change.
of work such that loading for related many-to-one objects is slightly more aggressive, in the case of a graph of self-referential objects that are to be deleted; the load of related objects is to help determine the correct order for deletion if passive_deletes is not set. - revert the changes to test_delete_unloaded_m2o, these deletes do in fact need to occur in the order of the two child objects first.