Relationships API

Object Name Description

backref(name, **kwargs)

Create a back reference with explicit keyword arguments, which are the same arguments one can send to relationship().

dynamic_loader(argument, **kw)

Construct a dynamically-loading mapper property.

foreign(expr)

Annotate a portion of a primaryjoin expression with a ‘foreign’ annotation.

relation(*arg, **kw)

A synonym for relationship().

relationship(argument[, secondary, primaryjoin, secondaryjoin, ...])

Provide a relationship between two mapped classes.

remote(expr)

Annotate a portion of a primaryjoin expression with a ‘remote’ annotation.
function sqlalchemy.orm.relationship(argument, secondary=None, primaryjoin=None, secondaryjoin=None, foreign_keys=None, uselist=None, order_by=False, backref=None, back_populates=None, post_update=False, cascade=False, extension=None, viewonly=False, lazy='select', collection_class=None, passive_deletes=False, passive_updates=True, remote_side=None, enable_typechecks=True, join_depth=None, comparator_factory=None, single_parent=False, innerjoin=False, distinct_target_key=None, doc=None, active_history=False, cascade_backrefs=True, load_on_pending=False, bake_queries=True, _local_remote_pairs=None, query_class=None, info=None, omit_join=None, sync_backref=None)

Provide a relationship between two mapped classes.

This corresponds to a parent-child or associative table relationship. The constructed class is an instance of RelationshipProperty.

A typical relationship(), used in a classical mapping:

mapper(Parent, properties={
  'children': relationship(Child)
})

Some arguments accepted by relationship() optionally accept a callable function, which when called produces the desired value. The callable is invoked by the parent Mapper at “mapper initialization” time, which happens only when mappers are first used, and is assumed to be after all mappings have been constructed. This can be used to resolve order-of-declaration and other dependency issues, such as if Child is declared below Parent in the same file:

mapper(Parent, properties={
    "children":relationship(lambda: Child,
                        order_by=lambda: Child.id)
})

When using the Declarative extension, the Declarative initializer allows string arguments to be passed to relationship(). These string arguments are converted into callables that evaluate the string as Python code, using the Declarative class-registry as a namespace. This allows the lookup of related classes to be automatic via their string name, and removes the need for related classes to be imported into the local module space before the dependent classes have been declared. It is still required that the modules in which these related classes appear are imported anywhere in the application at some point before the related mappings are actually used, else a lookup error will be raised when the relationship() attempts to resolve the string reference to the related class. An example of a string- resolved class is as follows:

from sqlalchemy.ext.declarative import declarative_base

Base = declarative_base()

class Parent(Base):
    __tablename__ = 'parent'
    id = Column(Integer, primary_key=True)
    children = relationship("Child", order_by="Child.id")

See also

Relationship Configuration - Full introductory and reference documentation for relationship().

Building a Relationship - ORM tutorial introduction.

Parameters:

  • argument –

    A mapped class, or actual Mapper instance, representing the target of the relationship.

    relationship.argument may also be passed as a callable function which is evaluated at mapper initialization time, and may be passed as a string name when using Declarative.

    Warning

    Prior to SQLAlchemy 1.3.16, this value is interpreted using Python’s eval() function. DO NOT PASS UNTRUSTED INPUT TO THIS STRING. See Evaluation of relationship arguments for details on declarative evaluation of relationship() arguments.

    See also

    Configuring Relationships - further detail on relationship configuration when using Declarative.

  • secondary –

    For a many-to-many relationship, specifies the intermediary table, and is typically an instance of Table. In less common circumstances, the argument may also be specified as an Alias construct, or even a Join construct.

    relationship.secondary may also be passed as a callable function which is evaluated at mapper initialization time. When using Declarative, it may also be a string argument noting the name of a Table that is present in the MetaData collection associated with the parent-mapped Table.

    Warning

    When passed as a Python-evaluable string, the argument is interpreted using Python’s eval() function. DO NOT PASS UNTRUSTED INPUT TO THIS STRING. See Evaluation of relationship arguments for details on declarative evaluation of relationship() arguments.

    The relationship.secondary keyword argument is typically applied in the case where the intermediary Table is not otherwise expressed in any direct class mapping. If the “secondary” table is also explicitly mapped elsewhere (e.g. as in Association Object), one should consider applying the relationship.viewonly flag so that this relationship() is not used for persistence operations which may conflict with those of the association object pattern.

    See also

    Many To Many - Reference example of “many to many”.

    Building a Many To Many Relationship - ORM tutorial introduction to many-to-many relationships.

    Self-Referential Many-to-Many Relationship - Specifics on using many-to-many in a self-referential case.

    Configuring Many-to-Many Relationships - Additional options when using Declarative.

    Association Object - an alternative to relationship.secondary when composing association table relationships, allowing additional attributes to be specified on the association table.

    Composite “Secondary” Joins - a lesser-used pattern which in some cases can enable complex relationship() SQL conditions to be used.

    New in version 0.9.2: relationship.secondary works more effectively when referring to a Join instance.

  • active_history=False – When True, indicates that the “previous” value for a many-to-one reference should be loaded when replaced, if not already loaded. Normally, history tracking logic for simple many-to-ones only needs to be aware of the “new” value in order to perform a flush. This flag is available for applications that make use of get_history() which also need to know the “previous” value of the attribute.

  • backref –

    Indicates the string name of a property to be placed on the related mapper’s class that will handle this relationship in the other direction. The other property will be created automatically when the mappers are configured. Can also be passed as a backref() object to control the configuration of the new relationship.

    See also

    Linking Relationships with Backref - Introductory documentation and examples.

    relationship.back_populates - alternative form of backref specification.

    backref() - allows control over relationship() configuration when using relationship.backref.

  • back_populates –

    Takes a string name and has the same meaning as relationship.backref, except the complementing property is not created automatically, and instead must be configured explicitly on the other mapper. The complementing property should also indicate relationship.back_populates to this relationship to ensure proper functioning.

    See also

    Linking Relationships with Backref - Introductory documentation and examples.

    relationship.backref - alternative form of backref specification.

  • bake_queries=True –

    Use the BakedQuery cache to cache the construction of SQL used in lazy loads. True by default. Set to False if the join condition of the relationship has unusual features that might not respond well to statement caching.

    Changed in version 1.2: “Baked” loading is the default implementation for the “select”, a.k.a. “lazy” loading strategy for relationships.

    New in version 1.0.0.

    See also

    Baked Queries

  • cascade –

    A comma-separated list of cascade rules which determines how Session operations should be “cascaded” from parent to child. This defaults to False, which means the default cascade should be used - this default cascade is "save-update, merge".

    The available cascades are save-update, merge, expunge, delete, delete-orphan, and refresh-expire. An additional option, all indicates shorthand for "save-update, merge, refresh-expire, expunge, delete", and is often used as in "all, delete-orphan" to indicate that related objects should follow along with the parent object in all cases, and be deleted when de-associated.

    See also

    Cascades - Full detail on each of the available cascade options.

    Configuring delete/delete-orphan Cascade - Tutorial example describing a delete cascade.

  • cascade_backrefs=True –

    A boolean value indicating if the save-update cascade should operate along an assignment event intercepted by a backref. When set to False, the attribute managed by this relationship will not cascade an incoming transient object into the session of a persistent parent, if the event is received via backref.

    See also

    Controlling Cascade on Backrefs - Full discussion and examples on how the relationship.cascade_backrefs option is used.

  • collection_class –

    A class or callable that returns a new list-holding object. will be used in place of a plain list for storing elements.

    See also

    Customizing Collection Access - Introductory documentation and examples.

  • comparator_factory –

    A class which extends Comparator which provides custom SQL clause generation for comparison operations.

    See also

    PropComparator - some detail on redefining comparators at this level.

    Operator Customization - Brief intro to this feature.

  • distinct_target_key=None –

    Indicate if a “subquery” eager load should apply the DISTINCT keyword to the innermost SELECT statement. When left as None, the DISTINCT keyword will be applied in those cases when the target columns do not comprise the full primary key of the target table. When set to True, the DISTINCT keyword is applied to the innermost SELECT unconditionally.

    It may be desirable to set this flag to False when the DISTINCT is reducing performance of the innermost subquery beyond that of what duplicate innermost rows may be causing.

    Changed in version 0.9.0: - relationship.distinct_target_key now defaults to None, so that the feature enables itself automatically for those cases where the innermost query targets a non-unique key.

    See also

    Relationship Loading Techniques - includes an introduction to subquery eager loading.

  • doc – Docstring which will be applied to the resulting descriptor.

  • extension –

    an AttributeExtension instance, or list of extensions, which will be prepended to the list of attribute listeners for the resulting descriptor placed on the class.

    Deprecated since version 0.7: AttributeExtension is deprecated in favor of the AttributeEvents listener interface. The relationship.extension parameter will be removed in a future release.

  • foreign_keys –

    A list of columns which are to be used as “foreign key” columns, or columns which refer to the value in a remote column, within the context of this relationship() object’s relationship.primaryjoin condition. That is, if the relationship.primaryjoin condition of this relationship() is a.id == b.a_id, and the values in b.a_id are required to be present in a.id, then the “foreign key” column of this relationship() is b.a_id.

    In normal cases, the relationship.foreign_keys parameter is not required. relationship() will automatically determine which columns in the relationship.primaryjoin condition are to be considered “foreign key” columns based on those Column objects that specify ForeignKey, or are otherwise listed as referencing columns in a ForeignKeyConstraint construct. relationship.foreign_keys is only needed when:

    1. There is more than one way to construct a join from the local table to the remote table, as there are multiple foreign key references present. Setting foreign_keys will limit the relationship() to consider just those columns specified here as “foreign”.

    2. The Table being mapped does not actually have ForeignKey or ForeignKeyConstraint constructs present, often because the table was reflected from a database that does not support foreign key reflection (MySQL MyISAM).

    3. The relationship.primaryjoin argument is used to construct a non-standard join condition, which makes use of columns or expressions that do not normally refer to their “parent” column, such as a join condition expressed by a complex comparison using a SQL function.

    The relationship() construct will raise informative error messages that suggest the use of the relationship.foreign_keys parameter when presented with an ambiguous condition. In typical cases, if relationship() doesn’t raise any exceptions, the relationship.foreign_keys parameter is usually not needed.

    relationship.foreign_keys may also be passed as a callable function which is evaluated at mapper initialization time, and may be passed as a Python-evaluable string when using Declarative.

    Warning

    When passed as a Python-evaluable string, the argument is interpreted using Python’s eval() function. DO NOT PASS UNTRUSTED INPUT TO THIS STRING. See Evaluation of relationship arguments for details on declarative evaluation of relationship() arguments.

    See also

    Handling Multiple Join Paths

    Creating Custom Foreign Conditions

    foreign() - allows direct annotation of the “foreign” columns within a relationship.primaryjoin condition.

  • info – Optional data dictionary which will be populated into the MapperProperty.info attribute of this object.

  • innerjoin=False –

    When True, joined eager loads will use an inner join to join against related tables instead of an outer join. The purpose of this option is generally one of performance, as inner joins generally perform better than outer joins.

    This flag can be set to True when the relationship references an object via many-to-one using local foreign keys that are not nullable, or when the reference is one-to-one or a collection that is guaranteed to have one or at least one entry.

    The option supports the same “nested” and “unnested” options as that of joinedload.innerjoin. See that flag for details on nested / unnested behaviors.

    See also

    joinedload.innerjoin - the option as specified by loader option, including detail on nesting behavior.

    What Kind of Loading to Use ? - Discussion of some details of various loader options.

  • join_depth –

    When non-None, an integer value indicating how many levels deep “eager” loaders should join on a self-referring or cyclical relationship. The number counts how many times the same Mapper shall be present in the loading condition along a particular join branch. When left at its default of None, eager loaders will stop chaining when they encounter a the same target mapper which is already higher up in the chain. This option applies both to joined- and subquery- eager loaders.

    See also

    Configuring Self-Referential Eager Loading - Introductory documentation and examples.

  • lazy='select' –

    specifies How the related items should be loaded. Default value is select. Values include:

    • select - items should be loaded lazily when the property is first accessed, using a separate SELECT statement, or identity map fetch for simple many-to-one references.

    • immediate - items should be loaded as the parents are loaded, using a separate SELECT statement, or identity map fetch for simple many-to-one references.

    • joined - items should be loaded “eagerly” in the same query as that of the parent, using a JOIN or LEFT OUTER JOIN. Whether the join is “outer” or not is determined by the relationship.innerjoin parameter.

    • subquery - items should be loaded “eagerly” as the parents are loaded, using one additional SQL statement, which issues a JOIN to a subquery of the original statement, for each collection requested.

    • selectin - items should be loaded “eagerly” as the parents are loaded, using one or more additional SQL statements, which issues a JOIN to the immediate parent object, specifying primary key identifiers using an IN clause.

      New in version 1.2.

    • noload - no loading should occur at any time. This is to support “write-only” attributes, or attributes which are populated in some manner specific to the application.

    • raise - lazy loading is disallowed; accessing the attribute, if its value were not already loaded via eager loading, will raise an InvalidRequestError. This strategy can be used when objects are to be detached from their attached Session after they are loaded.

      New in version 1.1.

    • raise_on_sql - lazy loading that emits SQL is disallowed; accessing the attribute, if its value were not already loaded via eager loading, will raise an InvalidRequestError, if the lazy load needs to emit SQL. If the lazy load can pull the related value from the identity map or determine that it should be None, the value is loaded. This strategy can be used when objects will remain associated with the attached Session, however additional SELECT statements should be blocked.

      New in version 1.1.

    • dynamic - the attribute will return a pre-configured Query object for all read operations, onto which further filtering operations can be applied before iterating the results. See the section Dynamic Relationship Loaders for more details.

    • True - a synonym for ‘select’

    • False - a synonym for ‘joined’

    • None - a synonym for ‘noload’

    See also

    Relationship Loading Techniques - Full documentation on relationship loader configuration.

    Dynamic Relationship Loaders - detail on the dynamic option.

    Setting Noload, RaiseLoad - notes on “noload” and “raise”

  • load_on_pending=False –

    Indicates loading behavior for transient or pending parent objects.

    When set to True, causes the lazy-loader to issue a query for a parent object that is not persistent, meaning it has never been flushed. This may take effect for a pending object when autoflush is disabled, or for a transient object that has been “attached” to a Session but is not part of its pending collection.

    The relationship.load_on_pending flag does not improve behavior when the ORM is used normally - object references should be constructed at the object level, not at the foreign key level, so that they are present in an ordinary way before a flush proceeds. This flag is not not intended for general use.

    See also

    Session.enable_relationship_loading() - this method establishes “load on pending” behavior for the whole object, and also allows loading on objects that remain transient or detached.

  • order_by –

    Indicates the ordering that should be applied when loading these items. relationship.order_by is expected to refer to one of the Column objects to which the target class is mapped, or the attribute itself bound to the target class which refers to the column.

    relationship.order_by may also be passed as a callable function which is evaluated at mapper initialization time, and may be passed as a Python-evaluable string when using Declarative.

    Warning

    When passed as a Python-evaluable string, the argument is interpreted using Python’s eval() function. DO NOT PASS UNTRUSTED INPUT TO THIS STRING. See Evaluation of relationship arguments for details on declarative evaluation of relationship() arguments.

  • passive_deletes=False –

    Indicates loading behavior during delete operations.

    A value of True indicates that unloaded child items should not be loaded during a delete operation on the parent. Normally, when a parent item is deleted, all child items are loaded so that they can either be marked as deleted, or have their foreign key to the parent set to NULL. Marking this flag as True usually implies an ON DELETE <CASCADE|SET NULL> rule is in place which will handle updating/deleting child rows on the database side.

    Additionally, setting the flag to the string value ‘all’ will disable the “nulling out” of the child foreign keys, when the parent object is deleted and there is no delete or delete-orphan cascade enabled. This is typically used when a triggering or error raise scenario is in place on the database side. Note that the foreign key attributes on in-session child objects will not be changed after a flush occurs so this is a very special use-case setting. Additionally, the “nulling out” will still occur if the child object is de-associated with the parent.

    See also

    Using foreign key ON DELETE cascade with ORM relationships - Introductory documentation and examples.

  • passive_updates=True –

    Indicates the persistence behavior to take when a referenced primary key value changes in place, indicating that the referencing foreign key columns will also need their value changed.

    When True, it is assumed that ON UPDATE CASCADE is configured on the foreign key in the database, and that the database will handle propagation of an UPDATE from a source column to dependent rows. When False, the SQLAlchemy relationship() construct will attempt to emit its own UPDATE statements to modify related targets. However note that SQLAlchemy cannot emit an UPDATE for more than one level of cascade. Also, setting this flag to False is not compatible in the case where the database is in fact enforcing referential integrity, unless those constraints are explicitly “deferred”, if the target backend supports it.

    It is highly advised that an application which is employing mutable primary keys keeps passive_updates set to True, and instead uses the referential integrity features of the database itself in order to handle the change efficiently and fully.

    See also

    Mutable Primary Keys / Update Cascades - Introductory documentation and examples.

    mapper.passive_updates - a similar flag which takes effect for joined-table inheritance mappings.

  • post_update –

    This indicates that the relationship should be handled by a second UPDATE statement after an INSERT or before a DELETE. Currently, it also will issue an UPDATE after the instance was UPDATEd as well, although this technically should be improved. This flag is used to handle saving bi-directional dependencies between two individual rows (i.e. each row references the other), where it would otherwise be impossible to INSERT or DELETE both rows fully since one row exists before the other. Use this flag when a particular mapping arrangement will incur two rows that are dependent on each other, such as a table that has a one-to-many relationship to a set of child rows, and also has a column that references a single child row within that list (i.e. both tables contain a foreign key to each other). If a flush operation returns an error that a “cyclical dependency” was detected, this is a cue that you might want to use relationship.post_update to “break” the cycle.

    See also

    Rows that point to themselves / Mutually Dependent Rows - Introductory documentation and examples.

  • primaryjoin –

    A SQL expression that will be used as the primary join of the child object against the parent object, or in a many-to-many relationship the join of the parent object to the association table. By default, this value is computed based on the foreign key relationships of the parent and child tables (or association table).

    relationship.primaryjoin may also be passed as a callable function which is evaluated at mapper initialization time, and may be passed as a Python-evaluable string when using Declarative.

    Warning

    When passed as a Python-evaluable string, the argument is interpreted using Python’s eval() function. DO NOT PASS UNTRUSTED INPUT TO THIS STRING. See Evaluation of relationship arguments for details on declarative evaluation of relationship() arguments.

    See also

    Specifying Alternate Join Conditions

  • remote_side –

    Used for self-referential relationships, indicates the column or list of columns that form the “remote side” of the relationship.

    relationship.remote_side may also be passed as a callable function which is evaluated at mapper initialization time, and may be passed as a Python-evaluable string when using Declarative.

    Warning

    When passed as a Python-evaluable string, the argument is interpreted using Python’s eval() function. DO NOT PASS UNTRUSTED INPUT TO THIS STRING. See Evaluation of relationship arguments for details on declarative evaluation of relationship() arguments.

    See also

    Adjacency List Relationships - in-depth explanation of how relationship.remote_side is used to configure self-referential relationships.

    remote() - an annotation function that accomplishes the same purpose as relationship.remote_side, typically when a custom relationship.primaryjoin condition is used.

  • query_class –

    A Query subclass that will be used as the base of the “appender query” returned by a “dynamic” relationship, that is, a relationship that specifies lazy="dynamic" or was otherwise constructed using the dynamic_loader() function.

    See also

    Dynamic Relationship Loaders - Introduction to “dynamic” relationship loaders.

  • secondaryjoin –

    A SQL expression that will be used as the join of an association table to the child object. By default, this value is computed based on the foreign key relationships of the association and child tables.

    relationship.secondaryjoin may also be passed as a callable function which is evaluated at mapper initialization time, and may be passed as a Python-evaluable string when using Declarative.

    Warning

    When passed as a Python-evaluable string, the argument is interpreted using Python’s eval() function. DO NOT PASS UNTRUSTED INPUT TO THIS STRING. See Evaluation of relationship arguments for details on declarative evaluation of relationship() arguments.

    See also

    Specifying Alternate Join Conditions

  • single_parent –

    When True, installs a validator which will prevent objects from being associated with more than one parent at a time. This is used for many-to-one or many-to-many relationships that should be treated either as one-to-one or one-to-many. Its usage is optional, except for relationship() constructs which are many-to-one or many-to-many and also specify the delete-orphan cascade option. The relationship() construct itself will raise an error instructing when this option is required.

    See also

    Cascades - includes detail on when the relationship.single_parent flag may be appropriate.

  • uselist –

    A boolean that indicates if this property should be loaded as a list or a scalar. In most cases, this value is determined automatically by relationship() at mapper configuration time, based on the type and direction of the relationship - one to many forms a list, many to one forms a scalar, many to many is a list. If a scalar is desired where normally a list would be present, such as a bi-directional one-to-one relationship, set relationship.uselist to False.

    The relationship.uselist flag is also available on an existing relationship() construct as a read-only attribute, which can be used to determine if this relationship() deals with collections or scalar attributes:

    >>> User.addresses.property.uselist
True

    See also

    One To One - Introduction to the “one to one” relationship pattern, which is typically when the relationship.uselist flag is needed.

  • viewonly=False –

    When set to True, the relationship is used only for loading objects, and not for any persistence operation. A relationship() which specifies relationship.viewonly can work with a wider range of SQL operations within the relationship.primaryjoin condition, including operations that feature the use of a variety of comparison operators as well as SQL functions such as cast(). The relationship.viewonly flag is also of general use when defining any kind of relationship() that doesn’t represent the full set of related objects, to prevent modifications of the collection from resulting in persistence operations.

    When using the relationship.viewonly flag in conjunction with backrefs, the relationship.sync_backref should be set to False; this indicates that the backref should not actually populate this relationship with data when changes occur on the other side; as this is a viewonly relationship, it cannot accommodate changes in state correctly as these will not be persisted.

    New in version 1.3.17: - the relationship.sync_backref flag set to False is required when using viewonly in conjunction with backrefs. A warning is emitted when this flag is not set.

    See also

    relationship.sync_backref

  • sync_backref –

    A boolean that enables the events used to synchronize the in-Python attributes when this relationship is target of either relationship.backref or relationship.back_populates.

    Defaults to None, which indicates that an automatic value should be selected based on the value of the relationship.viewonly flag. When left at its default, changes in state for writable relationships will be back-populated normally. For viewonly relationships, a warning is emitted unless the flag is set to False.

    New in version 1.3.17.

    See also

    relationship.viewonly

  • omit_join –

    Allows manual control over the “selectin” automatic join optimization. Set to False to disable the “omit join” feature added in SQLAlchemy 1.3; or leave as None to leave automatic optimization in place.

    Note

    This flag may only be set to False. It is not necessary to set it to True as the “omit_join” optimization is automatically detected; if it is not detected, then the optimization is not supported.

    Changed in version 1.3.11: setting omit_join to True will now emit a warning as this was not the intended use of this flag.

    New in version 1.3.

function sqlalchemy.orm.backref(name, **kwargs)

Create a back reference with explicit keyword arguments, which are the same arguments one can send to relationship().

Used with the backref keyword argument to relationship() in place of a string argument, e.g.:

'items':relationship(
    SomeItem, backref=backref('parent', lazy='subquery'))

See also

Linking Relationships with Backref

function sqlalchemy.orm.relation(*arg, **kw)

A synonym for relationship().

function sqlalchemy.orm.dynamic_loader(argument, **kw)

Construct a dynamically-loading mapper property.

This is essentially the same as using the lazy='dynamic' argument with relationship():

dynamic_loader(SomeClass)

# is the same as

relationship(SomeClass, lazy="dynamic")

See the section Dynamic Relationship Loaders for more details on dynamic loading.

function sqlalchemy.orm.foreign(expr)

Annotate a portion of a primaryjoin expression with a ‘foreign’ annotation.

See the section Creating Custom Foreign Conditions for a description of use.

See also

Creating Custom Foreign Conditions

remote()

function sqlalchemy.orm.remote(expr)

Annotate a portion of a primaryjoin expression with a ‘remote’ annotation.

See the section Creating Custom Foreign Conditions for a description of use.

See also

Creating Custom Foreign Conditions

foreign()