Functional constructs for ORM configuration.
See the SQLAlchemy object relational tutorial and mapper configuration documentation for an overview of how this module is used.
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)¶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.
argument¶ –
a mapped class, or actual Mapper
instance, representing
the target of the relationship.
argument
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.
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.
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
.
The 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
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
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.
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
attributes.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.
back_populates
- alternative form
of backref specification.
backref()
- allows control over relationship()
configuration when using backref
.
back_populates¶ –
Takes a string name and has the same meaning as
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
back_populates
to this relationship to
ensure proper functioning.
See also
Linking Relationships with Backref - Introductory documentation and examples.
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
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 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 RelationshipProperty.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: -
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 primaryjoin
condition.
That is, if the 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 foreign_keys
parameter is not required. relationship()
will
automatically determine which columns in the
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.
foreign_keys
is only needed when:
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 therelationship()
to consider just those columns specified here as “foreign”.The
Table
being mapped does not actually haveForeignKey
orForeignKeyConstraint
constructs present, often because the table was reflected from a database that does not support foreign key reflection (MySQL MyISAM).The
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
foreign_keys
parameter when
presented with an ambiguous condition. In typical cases,
if relationship()
doesn’t raise any exceptions, the
foreign_keys
parameter is usually
not needed.
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.
See also
Creating Custom Foreign Conditions
foreign()
- allows direct annotation of the “foreign”
columns within a 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
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 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. 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.
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.
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 Passive Deletes - 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 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 this child object against the parent object, or in a many-to-many relationship the join of the primary 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).
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.
See also
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.
See also
Adjacency List Relationships - in-depth explanation of how
remote_side
is used to configure self-referential relationships.
remote()
- an annotation function that accomplishes the
same purpose as remote_side
, typically
when a custom 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 orm.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.
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.
See also
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
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 uselist
to
False.
The 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
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 viewonly
can work
with a wider range of SQL operations within the
primaryjoin
condition, including
operations that feature the use of a variety of comparison operators
as well as SQL functions such as cast()
. The
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.
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.
New in version 1.3.
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
sqlalchemy.orm.
relation
(*arg, **kw)¶A synonym for relationship()
.
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.
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.
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.