The ORM includes a wide variety of hooks available for subscription.
New in version 0.7: The event supersedes the previous system of “extension” classes.
For an introduction to the event API, see Events. Non-ORM events such as those regarding connections and low-level statement execution are described in Core Events.
sqlalchemy.orm.events.
AttributeEvents
¶Bases: sqlalchemy.event.base.Events
Define events for object attributes.
These are typically defined on the class-bound descriptor for the target class.
e.g.:
from sqlalchemy import event
def my_append_listener(target, value, initiator):
print "received append event for target: %s" % target
event.listen(MyClass.collection, 'append', my_append_listener)
Listeners have the option to return a possibly modified version
of the value, when the retval=True
flag is passed
to listen()
:
def validate_phone(target, value, oldvalue, initiator):
"Strip non-numeric characters from a phone number"
return re.sub(r'(?![0-9])', '', value)
# setup listener on UserContact.phone attribute, instructing
# it to use the return value
listen(UserContact.phone, 'set', validate_phone, retval=True)
A validation function like the above can also raise an exception
such as ValueError
to halt the operation.
Several modifiers are available to the listen()
function.
Parameters: |
|
---|
append
(target, value, initiator)¶Receive a collection append event.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass.some_attribute, 'append')
def receive_append(target, value, initiator):
"listen for the 'append' event"
# ... (event handling logic) ...
Parameters: |
|
---|---|
Returns: | if the event was registered with |
dispose_collection
(target, collection, collection_adpater)¶Receive a ‘collection dispose’ event.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass.some_attribute, 'dispose_collection')
def receive_dispose_collection(target, collection, collection_adpater):
"listen for the 'dispose_collection' event"
# ... (event handling logic) ...
This event is triggered for a collection-based attribute when a collection is replaced, that is:
u1.addresses.append(a1)
u1.addresses = [a2, a3] # <- old collection is disposed
The mechanics of the event will typically include that the given collection is empty, even if it stored objects while being replaced.
New in version 1.0.0: the AttributeEvents.init_collection()
and AttributeEvents.dispose_collection()
events supersede
the collection.linker
hook.
init_collection
(target, collection, collection_adapter)¶Receive a ‘collection init’ event.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass.some_attribute, 'init_collection')
def receive_init_collection(target, collection, collection_adapter):
"listen for the 'init_collection' event"
# ... (event handling logic) ...
This event is triggered for a collection-based attribute, when the initial “empty collection” is first generated for a blank attribute, as well as for when the collection is replaced with a new one, such as via a set event.
E.g., given that User.addresses
is a relationship-based
collection, the event is triggered here:
u1 = User()
u1.addresses.append(a1) # <- new collection
and also during replace operations:
u1.addresess = [a2, a3] # <- new collection
Parameters: |
|
---|
New in version 1.0.0: the AttributeEvents.init_collection()
and AttributeEvents.dispose_collection()
events supersede
the collection.linker
hook.
remove
(target, value, initiator)¶Receive a collection remove event.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass.some_attribute, 'remove')
def receive_remove(target, value, initiator):
"listen for the 'remove' event"
# ... (event handling logic) ...
Parameters: |
|
---|---|
Returns: | No return value is defined for this event. |
set
(target, value, oldvalue, initiator)¶Receive a scalar set event.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass.some_attribute, 'set')
def receive_set(target, value, oldvalue, initiator):
"listen for the 'set' event"
# ... (event handling logic) ...
# named argument style (new in 0.9)
@event.listens_for(SomeClass.some_attribute, 'set', named=True)
def receive_set(**kw):
"listen for the 'set' event"
target = kw['target']
value = kw['value']
# ... (event handling logic) ...
Parameters: |
|
---|---|
Returns: | if the event was registered with |
sqlalchemy.orm.events.
MapperEvents
¶Bases: sqlalchemy.event.base.Events
Define events specific to mappings.
e.g.:
from sqlalchemy import event
def my_before_insert_listener(mapper, connection, target):
# execute a stored procedure upon INSERT,
# apply the value to the row to be inserted
target.calculated_value = connection.scalar(
"select my_special_function(%d)"
% target.special_number)
# associate the listener function with SomeClass,
# to execute during the "before_insert" hook
event.listen(
SomeClass, 'before_insert', my_before_insert_listener)
Available targets include:
propagate=True
flag)Mapper
objectsMapper
class itself and the mapper()
function indicate listening for all mappers.Changed in version 0.8.0: mapper events can be associated with unmapped superclasses of mapped classes.
Mapper events provide hooks into critical sections of the
mapper, including those related to object instrumentation,
object loading, and object persistence. In particular, the
persistence methods before_insert()
,
and before_update()
are popular
places to augment the state being persisted - however, these
methods operate with several significant restrictions. The
user is encouraged to evaluate the
SessionEvents.before_flush()
and
SessionEvents.after_flush()
methods as more
flexible and user-friendly hooks in which to apply
additional database state during a flush.
When using MapperEvents
, several modifiers are
available to the event.listen()
function.
Parameters: |
|
---|
after_configured
()¶Called after a series of mappers have been configured.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'after_configured')
def receive_after_configured():
"listen for the 'after_configured' event"
# ... (event handling logic) ...
This corresponds to the orm.configure_mappers()
call, which
note is usually called automatically as mappings are first
used.
This event can only be applied to the Mapper
class
or mapper()
function, and not to individual mappings or
mapped classes. It is only invoked for all mappings as a whole:
from sqlalchemy.orm import mapper
@event.listens_for(mapper, "after_configured")
def go():
# ...
Theoretically this event is called once per
application, but is actually called any time new mappers
have been affected by a orm.configure_mappers()
call. If new mappings are constructed after existing ones have
already been used, this event can be called again. To ensure
that a particular event is only called once and no further, the
once=True
argument (new in 0.9.4) can be applied:
from sqlalchemy.orm import mapper
@event.listens_for(mapper, "after_configured", once=True)
def go():
# ...
after_delete
(mapper, connection, target)¶Receive an object instance after a DELETE statement has been emitted corresponding to that instance.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'after_delete')
def receive_after_delete(mapper, connection, target):
"listen for the 'after_delete' event"
# ... (event handling logic) ...
This event is used to emit additional SQL statements on the given connection as well as to perform application specific bookkeeping related to a deletion event.
The event is often called for a batch of objects of the same class after their DELETE statements have been emitted at once in a previous step.
Warning
Mapper-level flush events are designed to operate on attributes
local to the immediate object being handled
and via SQL operations with the given Connection
only. Handlers here should not make alterations to the
state of the Session
overall, and in general should not
affect any relationship()
-mapped attributes, as
session cascade rules will not function properly, nor is it
always known if the related class has already been handled.
Operations that are not supported in mapper events include:
Session.add()
Session.delete()
someobject.related = someotherobject
Operations which manipulate the state of the object relative to other objects are better handled:
__init__()
method of the mapped object itself,
or another method designed to establish some particular state.@validates
handler, see Simple ValidatorsSessionEvents.before_flush()
event.Parameters: |
|
---|---|
Returns: | No return value is supported by this event. |
after_insert
(mapper, connection, target)¶Receive an object instance after an INSERT statement is emitted corresponding to that instance.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'after_insert')
def receive_after_insert(mapper, connection, target):
"listen for the 'after_insert' event"
# ... (event handling logic) ...
This event is used to modify in-Python-only state on the instance after an INSERT occurs, as well as to emit additional SQL statements on the given connection.
The event is often called for a batch of objects of the
same class after their INSERT statements have been
emitted at once in a previous step. In the extremely
rare case that this is not desirable, the
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 are designed to operate on attributes
local to the immediate object being handled
and via SQL operations with the given
Connection
only. Handlers here should not make
alterations to the state of the Session
overall, and in
general should not affect any relationship()
-mapped
attributes, as session cascade rules will not function properly,
nor is it always known if the related class has already been
handled. Operations that are not supported in mapper
events include:
Session.add()
Session.delete()
someobject.related = someotherobject
Operations which manipulate the state of the object relative to other objects are better handled:
__init__()
method of the mapped object itself,
or another method designed to establish some particular state.@validates
handler, see Simple ValidatorsSessionEvents.before_flush()
event.Parameters: |
|
---|---|
Returns: | No return value is supported by this event. |
after_update
(mapper, connection, target)¶Receive an object instance after an UPDATE statement is emitted corresponding to that instance.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@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 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 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 are designed to operate on attributes
local to the immediate object being handled
and via SQL operations with the given Connection
only. Handlers here should not make alterations to the
state of the Session
overall, and in general should not
affect any relationship()
-mapped attributes, as
session cascade rules will not function properly, nor is it
always known if the related class has already been handled.
Operations that are not supported in mapper events include:
Session.add()
Session.delete()
someobject.related = someotherobject
Operations which manipulate the state of the object relative to other objects are better handled:
__init__()
method of the mapped object itself,
or another method designed to establish some particular state.@validates
handler, see Simple ValidatorsSessionEvents.before_flush()
event.Parameters: |
|
---|---|
Returns: | No return value is supported by this event. |
before_configured
()¶Called before a series of mappers have been configured.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'before_configured')
def receive_before_configured():
"listen for the 'before_configured' event"
# ... (event handling logic) ...
This corresponds to the orm.configure_mappers()
call, which
note is usually called automatically as mappings are first
used.
This event can only be applied to the Mapper
class
or mapper()
function, and not to individual mappings or
mapped classes. It is only invoked for all mappings as a whole:
from sqlalchemy.orm import mapper
@event.listens_for(mapper, "before_configured")
def go():
# ...
Theoretically this event is called once per
application, but is actually called any time new mappers
are to be affected by a orm.configure_mappers()
call. If new mappings are constructed after existing ones have
already been used, this event can be called again. To ensure
that a particular event is only called once and no further, the
once=True
argument (new in 0.9.4) can be applied:
from sqlalchemy.orm import mapper
@event.listens_for(mapper, "before_configured", once=True)
def go():
# ...
New in version 0.9.3.
before_delete
(mapper, connection, target)¶Receive an object instance before a DELETE statement is emitted corresponding to that instance.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'before_delete')
def receive_before_delete(mapper, connection, target):
"listen for the 'before_delete' event"
# ... (event handling logic) ...
This event is used to emit additional SQL statements on the given connection as well as to perform application specific bookkeeping related to a deletion event.
The event is often called for a batch of objects of the same class before their DELETE statements are emitted at once in a later step.
Warning
Mapper-level flush events are designed to operate on attributes
local to the immediate object being handled
and via SQL operations with the given Connection
only. Handlers here should not make alterations to the
state of the Session
overall, and in general should not
affect any relationship()
-mapped attributes, as
session cascade rules will not function properly, nor is it
always known if the related class has already been handled.
Operations that are not supported in mapper events include:
Session.add()
Session.delete()
someobject.related = someotherobject
Operations which manipulate the state of the object relative to other objects are better handled:
__init__()
method of the mapped object itself,
or another method designed to establish some particular state.@validates
handler, see Simple ValidatorsSessionEvents.before_flush()
event.Parameters: |
|
---|---|
Returns: | No return value is supported by this event. |
before_insert
(mapper, connection, target)¶Receive an object instance before an INSERT statement is emitted corresponding to that instance.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'before_insert')
def receive_before_insert(mapper, connection, target):
"listen for the 'before_insert' event"
# ... (event handling logic) ...
This event is used to modify local, non-object related attributes on the instance before an INSERT occurs, as well as to emit additional SQL statements on the given connection.
The event is often called for a batch of objects of the
same class before their INSERT statements are emitted at
once in a later step. In the extremely rare case that
this is not desirable, the 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 are designed to operate on attributes
local to the immediate object being handled
and via SQL operations with the given
Connection
only. Handlers here should not make
alterations to the state of the Session
overall, and
in general should not affect any relationship()
-mapped
attributes, as session cascade rules will not function properly,
nor is it always known if the related class has already been
handled. Operations that are not supported in mapper
events include:
Session.add()
Session.delete()
someobject.related = someotherobject
Operations which manipulate the state of the object relative to other objects are better handled:
__init__()
method of the mapped object itself, or
another method designed to establish some particular state.@validates
handler, see Simple ValidatorsSessionEvents.before_flush()
event.Parameters: |
|
---|---|
Returns: | No return value is supported by this event. |
before_update
(mapper, connection, target)¶Receive an object instance before an UPDATE statement is emitted corresponding to that instance.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'before_update')
def receive_before_update(mapper, connection, target):
"listen for the 'before_update' event"
# ... (event handling logic) ...
This event is used to modify local, non-object related attributes on the instance before 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. 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 before_update()
is
not a guarantee that an UPDATE statement will be
issued, although you can affect the outcome here by
modifying attributes so that a net change in value does
exist.
To detect if the column-based attributes on the object have net
changes, and will therefore generate 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 before their UPDATE statements are emitted at
once in a later step. In the extremely rare case that
this is not desirable, the 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 are designed to operate on attributes
local to the immediate object being handled
and via SQL operations with the given Connection
only. Handlers here should not make alterations to the
state of the Session
overall, and in general should not
affect any relationship()
-mapped attributes, as
session cascade rules will not function properly, nor is it
always known if the related class has already been handled.
Operations that are not supported in mapper events include:
Session.add()
Session.delete()
someobject.related = someotherobject
Operations which manipulate the state of the object relative to other objects are better handled:
__init__()
method of the mapped object itself,
or another method designed to establish some particular state.@validates
handler, see Simple ValidatorsSessionEvents.before_flush()
event.Parameters: |
|
---|---|
Returns: | No return value is supported by this event. |
instrument_class
(mapper, class_)¶Receive a class when the mapper is first constructed, before instrumentation is applied to the mapped class.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'instrument_class')
def receive_instrument_class(mapper, class_):
"listen for the 'instrument_class' event"
# ... (event handling logic) ...
This event is the earliest phase of mapper construction. Most attributes of the mapper are not yet initialized.
This listener can either be applied to the Mapper
class overall, or to any un-mapped class which serves as a base
for classes that will be mapped (using the propagate=True
flag):
Base = declarative_base()
@event.listens_for(Base, "instrument_class", propagate=True)
def on_new_class(mapper, cls_):
" ... "
Parameters: |
---|
mapper_configured
(mapper, class_)¶Called when the mapper for the class is fully configured.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'mapper_configured')
def receive_mapper_configured(mapper, class_):
"listen for the 'mapper_configured' event"
# ... (event handling logic) ...
This event is the latest phase of mapper construction, and is invoked when the mapped classes are first used, so that relationships between mappers can be resolved. When the event is called, the mapper should be in its final state.
While the configuration event normally occurs automatically,
it can be forced to occur ahead of time, in the case where the event
is needed before any actual mapper usage, by using the
configure_mappers()
function.
Parameters: |
---|
sqlalchemy.orm.events.
InstanceEvents
¶Bases: sqlalchemy.event.base.Events
Define events specific to object lifecycle.
e.g.:
from sqlalchemy import event
def my_load_listener(target, context):
print "on load!"
event.listen(SomeClass, 'load', my_load_listener)
Available targets include:
propagate=True
flag)Mapper
objectsMapper
class itself and the mapper()
function indicate listening for all mappers.Changed in version 0.8.0: instance events can be associated with unmapped superclasses of mapped classes.
Instance events are closely related to mapper events, but are more specific to the instance and its instrumentation, rather than its system of persistence.
When using InstanceEvents
, several modifiers are
available to the event.listen()
function.
Parameters: |
|
---|
expire
(target, attrs)¶Receive an object instance after its attributes or some subset have been expired.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'expire')
def receive_expire(target, attrs):
"listen for the 'expire' event"
# ... (event handling logic) ...
‘keys’ is a list of attribute names. If None, the entire state was expired.
Parameters: |
|
---|
first_init
(manager, cls)¶Called when the first instance of a particular mapping is called.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'first_init')
def receive_first_init(manager, cls):
"listen for the 'first_init' event"
# ... (event handling logic) ...
init
(target, args, kwargs)¶Receive an instance when its constructor is called.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'init')
def receive_init(target, args, kwargs):
"listen for the 'init' event"
# ... (event handling logic) ...
This method is only called during a userland construction of an object. It is not called when an object is loaded from the database.
init_failure
(target, args, kwargs)¶Receive an instance when its constructor has been called, and raised an exception.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'init_failure')
def receive_init_failure(target, args, kwargs):
"listen for the 'init_failure' event"
# ... (event handling logic) ...
This method is only called during a userland construction of an object. It is not called when an object is loaded from the database.
load
(target, context)¶Receive an object instance after it has been created via
__new__
, and after initial attribute population has
occurred.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'load')
def receive_load(target, context):
"listen for the 'load' event"
# ... (event handling logic) ...
This typically occurs when the instance is created based on incoming result rows, and is only called once for that instance’s lifetime.
Note that during a result-row load, this method is called upon the first row received for this instance. Note that some attributes and collections may or may not be loaded or even initialized, depending on what’s present in the result rows.
Parameters: |
|
---|
pickle
(target, state_dict)¶Receive an object instance when its associated state is being pickled.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'pickle')
def receive_pickle(target, state_dict):
"listen for the 'pickle' event"
# ... (event handling logic) ...
Parameters: |
|
---|
refresh
(target, context, attrs)¶Receive an object instance after one or more attributes have been refreshed from a query.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'refresh')
def receive_refresh(target, context, attrs):
"listen for the 'refresh' event"
# ... (event handling logic) ...
Parameters: |
|
---|
refresh_flush
(target, flush_context, attrs)¶Receive an object instance after one or more attributes have been refreshed within the persistence of the object.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'refresh_flush')
def receive_refresh_flush(target, flush_context, attrs):
"listen for the 'refresh_flush' event"
# ... (event handling logic) ...
This event is the same as InstanceEvents.refresh()
except
it is invoked within the unit of work flush process, and the values
here typically come from the process of handling an INSERT or
UPDATE, such as via the RETURNING clause or from Python-side default
values.
New in version 1.0.5.
Parameters: |
|
---|
unpickle
(target, state_dict)¶Receive an object instance after its associated state has been unpickled.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeClass, 'unpickle')
def receive_unpickle(target, state_dict):
"listen for the 'unpickle' event"
# ... (event handling logic) ...
Parameters: |
|
---|
sqlalchemy.orm.events.
SessionEvents
¶Bases: sqlalchemy.event.base.Events
Define events specific to Session
lifecycle.
e.g.:
from sqlalchemy import event
from sqlalchemy.orm import sessionmaker
def my_before_commit(session):
print "before commit!"
Session = sessionmaker()
event.listen(Session, "before_commit", my_before_commit)
The listen()
function will accept
Session
objects as well as the return result
of sessionmaker()
and scoped_session()
.
Additionally, it accepts the Session
class which
will apply listeners to all Session
instances
globally.
after_attach
(session, instance)¶Execute after an instance is attached to a session.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'after_attach')
def receive_after_attach(session, instance):
"listen for the 'after_attach' event"
# ... (event handling logic) ...
This is called after an add, delete or merge.
Note
As of 0.8, this event fires off after the item
has been fully associated with the session, which is
different than previous releases. For event
handlers that require the object not yet
be part of session state (such as handlers which
may autoflush while the target object is not
yet complete) consider the
new before_attach()
event.
See also
after_begin
(session, transaction, connection)¶Execute after a transaction is begun on a connection
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'after_begin')
def receive_after_begin(session, transaction, connection):
"listen for the 'after_begin' event"
# ... (event handling logic) ...
Parameters: |
|
---|
after_bulk_delete
(delete_context)¶Execute after a bulk delete operation to the session.
Example argument forms:
from sqlalchemy import event
# standard decorator style (arguments as of 0.9)
@event.listens_for(SomeSessionOrFactory, 'after_bulk_delete')
def receive_after_bulk_delete(delete_context):
"listen for the 'after_bulk_delete' event"
# ... (event handling logic) ...
# legacy calling style (pre-0.9)
@event.listens_for(SomeSessionOrFactory, 'after_bulk_delete')
def receive_after_bulk_delete(session, query, query_context, result):
"listen for the 'after_bulk_delete' event"
# ... (event handling logic) ...
Changed in version 0.9: The after_bulk_delete
event now accepts the
arguments delete_context
.
Listener functions which accept the previous argument
signature(s) listed above will be automatically
adapted to the new signature.
This is called as a result of the Query.delete()
method.
Parameters: | delete_context¶ – a “delete context” object which contains details about the update, including these attributes:
|
---|
after_bulk_update
(update_context)¶Execute after a bulk update operation to the session.
Example argument forms:
from sqlalchemy import event
# standard decorator style (arguments as of 0.9)
@event.listens_for(SomeSessionOrFactory, 'after_bulk_update')
def receive_after_bulk_update(update_context):
"listen for the 'after_bulk_update' event"
# ... (event handling logic) ...
# legacy calling style (pre-0.9)
@event.listens_for(SomeSessionOrFactory, 'after_bulk_update')
def receive_after_bulk_update(session, query, query_context, result):
"listen for the 'after_bulk_update' event"
# ... (event handling logic) ...
Changed in version 0.9: The after_bulk_update
event now accepts the
arguments update_context
.
Listener functions which accept the previous argument
signature(s) listed above will be automatically
adapted to the new signature.
This is called as a result of the Query.update()
method.
Parameters: | update_context¶ – an “update context” object which contains details about the update, including these attributes:
|
---|
after_commit
(session)¶Execute after a commit has occurred.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'after_commit')
def receive_after_commit(session):
"listen for the 'after_commit' event"
# ... (event handling logic) ...
Note
The after_commit()
hook is not per-flush,
that is, the Session
can emit SQL to the database
many times within the scope of a transaction.
For interception of these events, use the
before_flush()
,
after_flush()
, or
after_flush_postexec()
events.
Note
The Session
is not in an active transaction
when the after_commit()
event is invoked,
and therefore can not emit SQL. To emit SQL corresponding to
every transaction, use the before_commit()
event.
Parameters: | session¶ – The target Session . |
---|
after_flush
(session, flush_context)¶Execute after flush has completed, but before commit has been called.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'after_flush')
def receive_after_flush(session, flush_context):
"listen for the 'after_flush' event"
# ... (event handling logic) ...
Note that the session’s state is still in pre-flush, i.e. ‘new’, ‘dirty’, and ‘deleted’ lists still show pre-flush state as well as the history settings on instance attributes.
Parameters: |
|
---|
after_flush_postexec
(session, flush_context)¶Execute after flush has completed, and after the post-exec state occurs.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'after_flush_postexec')
def receive_after_flush_postexec(session, flush_context):
"listen for the 'after_flush_postexec' event"
# ... (event handling logic) ...
This will be when the ‘new’, ‘dirty’, and ‘deleted’ lists are in their final state. An actual commit() may or may not have occurred, depending on whether or not the flush started its own transaction or participated in a larger transaction.
Parameters: |
|
---|
after_rollback
(session)¶Execute after a real DBAPI rollback has occurred.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'after_rollback')
def receive_after_rollback(session):
"listen for the 'after_rollback' event"
# ... (event handling logic) ...
Note that this event only fires when the actual rollback against
the database occurs - it does not fire each time the
Session.rollback()
method is called, if the underlying
DBAPI transaction has already been rolled back. In many
cases, the Session
will not be in
an “active” state during this event, as the current
transaction is not valid. To acquire a Session
which is active after the outermost rollback has proceeded,
use the SessionEvents.after_soft_rollback()
event, checking the
Session.is_active
flag.
Parameters: | session¶ – The target Session . |
---|
after_soft_rollback
(session, previous_transaction)¶Execute after any rollback has occurred, including “soft” rollbacks that don’t actually emit at the DBAPI level.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'after_soft_rollback')
def receive_after_soft_rollback(session, previous_transaction):
"listen for the 'after_soft_rollback' event"
# ... (event handling logic) ...
This corresponds to both nested and outer rollbacks, i.e. the innermost rollback that calls the DBAPI’s rollback() method, as well as the enclosing rollback calls that only pop themselves from the transaction stack.
The given Session
can be used to invoke SQL and
Session.query()
operations after an outermost rollback
by first checking the Session.is_active
flag:
@event.listens_for(Session, "after_soft_rollback")
def do_something(session, previous_transaction):
if session.is_active:
session.execute("select * from some_table")
Parameters: |
|
---|
New in version 0.7.3.
after_transaction_create
(session, transaction)¶Execute when a new SessionTransaction
is created.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'after_transaction_create')
def receive_after_transaction_create(session, transaction):
"listen for the 'after_transaction_create' event"
# ... (event handling logic) ...
This event differs from after_begin()
in that it occurs for each SessionTransaction
overall, as opposed to when transactions are begun
on individual database connections. It is also invoked
for nested transactions and subtransactions, and is always
matched by a corresponding
after_transaction_end()
event
(assuming normal operation of the Session
).
Parameters: |
|
---|
New in version 0.8.
See also
after_transaction_end
(session, transaction)¶Execute when the span of a SessionTransaction
ends.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'after_transaction_end')
def receive_after_transaction_end(session, transaction):
"listen for the 'after_transaction_end' event"
# ... (event handling logic) ...
This event differs from after_commit()
in that it corresponds to all SessionTransaction
objects in use, including those for nested transactions
and subtransactions, and is always matched by a corresponding
after_transaction_create()
event.
Parameters: |
|
---|
New in version 0.8.
See also
before_attach
(session, instance)¶Execute before an instance is attached to a session.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'before_attach')
def receive_before_attach(session, instance):
"listen for the 'before_attach' event"
# ... (event handling logic) ...
This is called before an add, delete or merge causes the object to be part of the session.
New in version 0.8.: Note that after_attach()
now fires off after the item is part of the session.
before_attach()
is provided for those cases where
the item should not yet be part of the session state.
See also
before_commit
(session)¶Execute before commit is called.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'before_commit')
def receive_before_commit(session):
"listen for the 'before_commit' event"
# ... (event handling logic) ...
Note
The before_commit()
hook is not per-flush,
that is, the Session
can emit SQL to the database
many times within the scope of a transaction.
For interception of these events, use the
before_flush()
,
after_flush()
, or
after_flush_postexec()
events.
Parameters: | session¶ – The target Session . |
---|
before_flush
(session, flush_context, instances)¶Execute before flush process has started.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeSessionOrFactory, 'before_flush')
def receive_before_flush(session, flush_context, instances):
"listen for the 'before_flush' event"
# ... (event handling logic) ...
Parameters: |
|
---|
sqlalchemy.orm.events.
QueryEvents
¶Bases: sqlalchemy.event.base.Events
Represent events within the construction of a Query
object.
The events here are intended to be used with an as-yet-unreleased
inspection system for Query
. Some very basic operations
are possible now, however the inspection system is intended to allow
complex query manipulations to be automated.
New in version 1.0.0.
before_compile
(query)¶Receive the Query
object before it is composed into a
core Select
object.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeQuery, 'before_compile')
def receive_before_compile(query):
"listen for the 'before_compile' event"
# ... (event handling logic) ...
This event is intended to allow changes to the query given:
@event.listens_for(Query, "before_compile", retval=True)
def no_deleted(query):
for desc in query.column_descriptions:
if desc['type'] is User:
entity = desc['expr']
query = query.filter(entity.deleted == False)
return query
The event should normally be listened with the retval=True
parameter set, so that the modified query may be returned.
Defines SQLAlchemy’s system of class instrumentation.
This module is usually not directly visible to user applications, but defines a large part of the ORM’s interactivity.
instrumentation.py deals with registration of end-user classes for state tracking. It interacts closely with state.py and attributes.py which establish per-instance and per-class-attribute instrumentation, respectively.
The class instrumentation system can be customized on a per-class
or global basis using the sqlalchemy.ext.instrumentation
module, which provides the means to build and specify
alternate instrumentation forms.
sqlalchemy.orm.events.
InstrumentationEvents
¶Bases: sqlalchemy.event.base.Events
Events related to class instrumentation events.
The listeners here support being established against any new style class, that is any object that is a subclass of ‘type’. Events will then be fired off for events against that class. If the “propagate=True” flag is passed to event.listen(), the event will fire off for subclasses of that class as well.
The Python type
builtin is also accepted as a target,
which when used has the effect of events being emitted
for all classes.
Note the “propagate” flag here is defaulted to True
,
unlike the other class level events where it defaults
to False
. This means that new subclasses will also
be the subject of these events, when a listener
is established on a superclass.
Changed in version 0.8: - events here will emit based
on comparing the incoming class to the type of class
passed to event.listen()
. Previously, the
event would fire for any class unconditionally regardless
of what class was sent for listening, despite
documentation which stated the contrary.
attribute_instrument
(cls, key, inst)¶Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeBaseClass, 'attribute_instrument')
def receive_attribute_instrument(cls, key, inst):
"listen for the 'attribute_instrument' event"
# ... (event handling logic) ...
Called when an attribute is instrumented.
class_instrument
(cls)¶Called after the given class is instrumented.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeBaseClass, 'class_instrument')
def receive_class_instrument(cls):
"listen for the 'class_instrument' event"
# ... (event handling logic) ...
To get at the ClassManager
, use
manager_of_class()
.
class_uninstrument
(cls)¶Called before the given class is uninstrumented.
Example argument forms:
from sqlalchemy import event
# standard decorator style
@event.listens_for(SomeBaseClass, 'class_uninstrument')
def receive_class_uninstrument(cls):
"listen for the 'class_uninstrument' event"
# ... (event handling logic) ...
To get at the ClassManager
, use
manager_of_class()
.