Release: 2.0.29 | Release Date: March 23, 2024

# SQLAlchemy 2.0 Documentation

# Events

SQLAlchemy includes an event API which publishes a wide variety of hooks into the internals of both SQLAlchemy Core and ORM.

## Event Registration

Subscribing to an event occurs through a single API point, the `listen()` function, or alternatively the `listens_for()` decorator. These functions accept a target, a string identifier which identifies the event to be intercepted, and a user-defined listening function. Additional positional and keyword arguments to these two functions may be supported by specific types of events, which may specify alternate interfaces for the given event function, or provide instructions regarding secondary event targets based on the given target.

The name of an event and the argument signature of a corresponding listener function is derived from a class bound specification method, which exists bound to a marker class that’s described in the documentation. For example, the documentation for `PoolEvents.connect()` indicates that the event name is `"connect"` and that a user-defined listener function should receive two positional arguments:

    from sqlalchemy.event import listen
    from sqlalchemy.pool import Pool

    def my_on_connect(dbapi_con, connection_record):
        print("New DBAPI connection:", dbapi_con)

    listen(Pool, "connect", my_on_connect)

To listen with the `listens_for()` decorator looks like:

    from sqlalchemy.event import listens_for
    from sqlalchemy.pool import Pool

    @listens_for(Pool, "connect")
    def my_on_connect(dbapi_con, connection_record):
        print("New DBAPI connection:", dbapi_con)

## Named Argument Styles

There are some varieties of argument styles which can be accepted by listener functions. Taking the example of `PoolEvents.connect()`, this function is documented as receiving `dbapi_connection` and `connection_record` arguments. We can opt to receive these arguments by name, by establishing a listener function that accepts `**keyword` arguments, by passing `named=True` to either `listen()` or `listens_for()`:

    from sqlalchemy.event import listens_for
    from sqlalchemy.pool import Pool

    @listens_for(Pool, "connect", named=True)
    def my_on_connect(**kw):
        print("New DBAPI connection:", kw["dbapi_connection"])

When using named argument passing, the names listed in the function argument specification will be used as keys in the dictionary.

Named style passes all arguments by name regardless of the function signature, so specific arguments may be listed as well, in any order, as long as the names match up:

    from sqlalchemy.event import listens_for
    from sqlalchemy.pool import Pool

    @listens_for(Pool, "connect", named=True)
    def my_on_connect(dbapi_connection, **kw):
        print("New DBAPI connection:", dbapi_connection)
        print("Connection record:", kw["connection_record"])

Above, the presence of `**kw` tells `listens_for()` that arguments should be passed to the function by name, rather than positionally.

## Targets

The `listen()` function is very flexible regarding targets. It generally accepts classes, instances of those classes, and related classes or objects from which the appropriate target can be derived. For example, the above mentioned `"connect"` event accepts `Engine` classes and objects as well as `Pool` classes and objects:

    from sqlalchemy.event import listen
    from sqlalchemy.pool import Pool, QueuePool
    from sqlalchemy import create_engine
    from sqlalchemy.engine import Engine
    import psycopg2

    def connect():
        return psycopg2.connect(user="ed", host="127.0.0.1", dbname="test")

    my_pool = QueuePool(connect)
    my_engine = create_engine("postgresql+psycopg2://ed@localhost/test")

    # associate listener with all instances of Pool
    listen(Pool, "connect", my_on_connect)

    # associate listener with all instances of Pool
    # via the Engine class
    listen(Engine, "connect", my_on_connect)

    # associate listener with my_pool
    listen(my_pool, "connect", my_on_connect)

    # associate listener with my_engine.pool
    listen(my_engine, "connect", my_on_connect)

## Modifiers

Some listeners allow modifiers to be passed to `listen()`. These modifiers sometimes provide alternate calling signatures for listeners. Such as with ORM events, some event listeners can have a return value which modifies the subsequent handling. By default, no listener ever requires a return value, but by passing `retval=True` this value can be supported:

    def validate_phone(target, value, oldvalue, initiator):
        """Strip non-numeric characters from a phone number"""

        return re.sub(r"\D", "", value)

    # setup listener on UserContact.phone attribute, instructing
    # it to use the return value
    listen(UserContact.phone, "set", validate_phone, retval=True)

## Events and Multiprocessing

SQLAlchemy’s event hooks are implemented with Python functions and objects, so events propagate via Python function calls. Python multiprocessing follows the same way we think about OS multiprocessing, such as a parent process forking a child process, thus we can describe the SQLAlchemy event system’s behavior using the same model.

Event hooks registered in a parent process will be present in new child processes that are forked from that parent after the hooks have been registered, since the child process starts with a copy of all existing Python structures from the parent when spawned. Child processes that already exist before the hooks are registered will not receive those new event hooks, as changes made to Python structures in a parent process do not propagate to child processes.

For the events themselves, these are Python function calls, which do not have any ability to propagate between processes. SQLAlchemy’s event system does not implement any inter-process communication. It is possible to implement event hooks that use Python inter-process messaging within them, however this would need to be implemented by the user.

## Event Reference

Both SQLAlchemy Core and SQLAlchemy ORM feature a wide variety of event hooks:

- Core Events - these are described in Core Events and include event hooks specific to connection pool lifecycle, SQL statement execution, transaction lifecycle, and schema creation and teardown.

- ORM Events - these are described in ORM Events, and include event hooks specific to class and attribute instrumentation, object initialization hooks, attribute on-change hooks, session state, flush, and commit hooks, mapper initialization, object/result population, and per-instance persistence hooks.

## API Reference

Object Name | Description
--- | ---
contains(target, identifier, fn) | Return True if the given target/ident/fn is set up to listen.
listen(target, identifier, fn, *args, **kw) | Register a listener function for the given target.
listens_for(target, identifier, *args, **kw) | Decorate a function as a listener for the given target + identifier.
remove(target, identifier, fn) | Remove an event listener.

function sqlalchemy.event.listen(target: Any, identifier: str, fn: Callable[[...], Any], *args: Any, **kw: Any) → None

  Register a listener function for the given target.

  The `listen()` function is part of the primary interface for the SQLAlchemy event system, documented at Events.

  e.g.:

      from sqlalchemy import event
      from sqlalchemy.schema import UniqueConstraint

      def unique_constraint_name(const, table):
          const.name = "uq_%s_%s" % (
              table.name,
              list(const.columns)[0].name
          )
      event.listen(
              UniqueConstraint,
              "after_parent_attach",
              unique_constraint_name)

  Parameters:

    - insert (bool) – The default behavior for event handlers is to append the decorated user defined function to an internal list of registered event listeners upon discovery. If a user registers a function with `insert=True`, SQLAlchemy will insert (prepend) the function to the internal list upon discovery. This feature is not typically used or recommended by the SQLAlchemy maintainers, but is provided to ensure certain user defined functions can run before others, such as when Changing the sql_mode in MySQL.

    - named (bool) – When using named argument passing, the names listed in the function argument specification will be used as keys in the dictionary. See Named Argument Styles.

    - once (bool) – Private/Internal API usage. Deprecated. This parameter would provide that an event function would run only once per given target. It does not however imply automatic de-registration of the listener function; associating an arbitrarily high number of listeners without explicitly removing them will cause memory to grow unbounded even if `once=True` is specified.

    - propagate (bool) – The `propagate` kwarg is available when working with ORM instrumentation and mapping events. See `MapperEvents` and `MapperEvents.before_mapper_configured()` for examples.

    - retval (bool) –

      This flag applies only to specific event listeners, each of which includes documentation explaining when it should be used. By default, no listener ever requires a return value. However, some listeners do support special behaviors for return values, and include in their documentation that the `retval=True` flag is necessary for a return value to be processed.

      Event listener suites that make use of `listen.retval` include `ConnectionEvents` and `AttributeEvents`.

  Note

  The `listen()` function cannot be called at the same time that the target event is being run. This has implications for thread safety, and also means an event cannot be added from inside the listener function for itself. The list of events to be run are present inside of a mutable collection that can’t be changed during iteration.

  Event registration and removal is not intended to be a “high velocity” operation; it is a configurational operation. For systems that need to quickly associate and deassociate with events at high scale, use a mutable structure that is handled from inside of a single listener.

  See also

  `listens_for()`

  `remove()`

function sqlalchemy.event.listens_for(target: Any, identifier: str, *args: Any, **kw: Any) → Callable[[Callable[[...], Any]], Callable[[...], Any]]

  Decorate a function as a listener for the given target + identifier.

  The `listens_for()` decorator is part of the primary interface for the SQLAlchemy event system, documented at Events.

  This function generally shares the same kwargs as `listens()`.

  e.g.:

      from sqlalchemy import event
      from sqlalchemy.schema import UniqueConstraint

      @event.listens_for(UniqueConstraint, "after_parent_attach")
      def unique_constraint_name(const, table):
          const.name = "uq_%s_%s" % (
              table.name,
              list(const.columns)[0].name
          )

  A given function can also be invoked for only the first invocation of the event using the `once` argument:

      @event.listens_for(Mapper, "before_configure", once=True)
      def on_config():
          do_config()

  Warning

  The `once` argument does not imply automatic de-registration of the listener function after it has been invoked a first time; a listener entry will remain associated with the target object. Associating an arbitrarily high number of listeners without explicitly removing them will cause memory to grow unbounded even if `once=True` is specified.

  See also

  `listen()` - general description of event listening

function sqlalchemy.event.remove(target: Any, identifier: str, fn: Callable[[...], Any]) → None

  Remove an event listener.

  The arguments here should match exactly those which were sent to `listen()`; all the event registration which proceeded as a result of this call will be reverted by calling `remove()` with the same arguments.

  e.g.:

      # if a function was registered like this...
      @event.listens_for(SomeMappedClass, "before_insert", propagate=True)
      def my_listener_function(*arg):
          pass

      # ... it's removed like this
      event.remove(SomeMappedClass, "before_insert", my_listener_function)

  Above, the listener function associated with `SomeMappedClass` was also propagated to subclasses of `SomeMappedClass`; the `remove()` function will revert all of these operations.

  Note

  The `remove()` function cannot be called at the same time that the target event is being run. This has implications for thread safety, and also means an event cannot be removed from inside the listener function for itself. The list of events to be run are present inside of a mutable collection that can’t be changed during iteration.

  Event registration and removal is not intended to be a “high velocity” operation; it is a configurational operation. For systems that need to quickly associate and deassociate with events at high scale, use a mutable structure that is handled from inside of a single listener.

  See also

  `listen()`

function sqlalchemy.event.contains(target: Any, identifier: str, fn: Callable[[...], Any]) → bool

  Return True if the given target/ident/fn is set up to listen.