Participer au site avec un Tip
Rechercher
 

Améliorations / Corrections

Vous avez des améliorations (ou des corrections) à proposer pour ce document : je vous remerçie par avance de m'en faire part, cela m'aide à améliorer le site.

Emplacement :

Description des améliorations :

Classe « MapperEvents »

Méthode sqlalchemy.orm.MapperEvents.after_update

Signature de la méthode after_update

def after_update(self, mapper, connection, target) 

Description

after_update.__doc__

Receive an object instance after an UPDATE statement
is emitted corresponding to that instance.

.. container:: event_signatures

     Example argument forms::

        from sqlalchemy import event


        @event.listens_for(SomeClass, 'after_update')
        def receive_after_update(mapper, connection, target):
            "listen for the 'after_update' event"

            # ... (event handling logic) ...


This event is used to modify in-Python-only
state on the instance after an UPDATE occurs, as well
as to emit additional SQL statements on the given
connection.

This method is called for all instances that are
marked as "dirty", *even those which have no net changes
to their column-based attributes*, and for which
no UPDATE statement has proceeded. An object is marked
as dirty when any of its column-based attributes have a
"set attribute" operation called or when any of its
collections are modified. If, at update time, no
column-based attributes have any net changes, no UPDATE
statement will be issued. This means that an instance
being sent to :meth:`~.MapperEvents.after_update` is
*not* a guarantee that an UPDATE statement has been
issued.

To detect if the column-based attributes on the object have net
changes, and therefore resulted in an UPDATE statement, use
``object_session(instance).is_modified(instance,
include_collections=False)``.

The event is often called for a batch of objects of the
same class after their UPDATE statements have been emitted at
once in a previous step. In the extremely rare case that
this is not desirable, the :func:`.mapper` can be
configured with ``batch=False``, which will cause
batches of instances to be broken up into individual
(and more poorly performing) event->persist->event
steps.

.. warning::

    Mapper-level flush events only allow **very limited operations**,
    on attributes local to the row being operated upon only,
    as well as allowing any SQL to be emitted on the given
    :class:`_engine.Connection`.  **Please read fully** the notes
    at :ref:`session_persistence_mapper` for guidelines on using
    these methods; generally, the :meth:`.SessionEvents.before_flush`
    method should be preferred for general on-flush changes.

:param mapper: the :class:`_orm.Mapper` which is the target
 of this event.
:param connection: the :class:`_engine.Connection` being used to
 emit UPDATE statements for this instance.  This
 provides a handle into the current transaction on the
 target database specific to this instance.
:param target: the mapped instance being persisted.  If
 the event is configured with ``raw=True``, this will
 instead be the :class:`.InstanceState` state-management
 object associated with the instance.
:return: No return value is supported by this event.

.. seealso::

    :ref:`session_persistence_events`