Using the legacy ‘backref’ relationship parameter

Note

The relationship.backref keyword should be considered legacy, and use of relationship.back_populates with explicit relationship() constructs should be preferred. Using individual relationship() constructs provides advantages including that both ORM mapped classes will include their attributes up front as the class is constructed, rather than as a deferred step, and configuration is more straightforward as all arguments are explicit. New PEP 484 features in SQLAlchemy 2.0 also take advantage of attributes being explicitly present in source code rather than using dynamic attribute generation.

See also

For general information about bidirectional relationships, see the following sections:

Working with Related Objects - in the SQLAlchemy Unified Tutorial, presents an overview of bi-directional relationship configuration and behaviors using relationship.back_populates

Behavior of save-update cascade with bi-directional relationships - notes on bi-directional relationship() behavior regarding Session cascade behaviors.

relationship.back_populates

The relationship.backref keyword argument on the relationship() construct allows the automatic generation of a new relationship() that will be automatically be added to the ORM mapping for the related class. It will then be placed into a relationship.back_populates configuration against the current relationship() being configured, with both relationship() constructs referring to each other.

Starting with the following example:

  1. from sqlalchemy import Column, ForeignKey, Integer, String
  2. from sqlalchemy.orm import DeclarativeBase, relationship
  3. class Base(DeclarativeBase):
  4. pass
  5. class User(Base):
  6. __tablename__ = "user"
  7. id = mapped_column(Integer, primary_key=True)
  8. name = mapped_column(String)
  9. addresses = relationship("Address", backref="user")
  10. class Address(Base):
  11. __tablename__ = "address"
  12. id = mapped_column(Integer, primary_key=True)
  13. email = mapped_column(String)
  14. user_id = mapped_column(Integer, ForeignKey("user.id"))

The above configuration establishes a collection of Address objects on User called User.addresses. It also establishes a .user attribute on Address which will refer to the parent User object. Using relationship.back_populates it’s equivalent to the following:

  1. from sqlalchemy import Column, ForeignKey, Integer, String
  2. from sqlalchemy.orm import DeclarativeBase, relationship
  3. class Base(DeclarativeBase):
  4. pass
  5. class User(Base):
  6. __tablename__ = "user"
  7. id = mapped_column(Integer, primary_key=True)
  8. name = mapped_column(String)
  9. addresses = relationship("Address", back_populates="user")
  10. class Address(Base):
  11. __tablename__ = "address"
  12. id = mapped_column(Integer, primary_key=True)
  13. email = mapped_column(String)
  14. user_id = mapped_column(Integer, ForeignKey("user.id"))
  15. user = relationship("User", back_populates="addresses")

The behavior of the User.addresses and Address.user relationships is that they now behave in a bi-directional way, indicating that changes on one side of the relationship impact the other. An example and discussion of this behavior is in the SQLAlchemy Unified Tutorial at Working with Related Objects.

Backref Default Arguments

Since relationship.backref generates a whole new relationship(), the generation process by default will attempt to include corresponding arguments in the new relationship() that correspond to the original arguments. As an example, below is a relationship() that includes a custom join condition which also includes the relationship.backref keyword:

  1. from sqlalchemy import Column, ForeignKey, Integer, String
  2. from sqlalchemy.orm import DeclarativeBase, relationship
  3. class Base(DeclarativeBase):
  4. pass
  5. class User(Base):
  6. __tablename__ = "user"
  7. id = mapped_column(Integer, primary_key=True)
  8. name = mapped_column(String)
  9. addresses = relationship(
  10. "Address",
  11. primaryjoin=(
  12. "and_(User.id==Address.user_id, Address.email.startswith('tony'))"
  13. ),
  14. backref="user",
  15. )
  16. class Address(Base):
  17. __tablename__ = "address"
  18. id = mapped_column(Integer, primary_key=True)
  19. email = mapped_column(String)
  20. user_id = mapped_column(Integer, ForeignKey("user.id"))

When the “backref” is generated, the relationship.primaryjoin condition is copied to the new relationship() as well:

  1. >>> print(User.addresses.property.primaryjoin)
  2. "user".id = address.user_id AND address.email LIKE :email_1 || '%%'
  3. >>>
  4. >>> print(Address.user.property.primaryjoin)
  5. "user".id = address.user_id AND address.email LIKE :email_1 || '%%'
  6. >>>

Other arguments that are transferrable include the relationship.secondary parameter that refers to a many-to-many association table, as well as the “join” arguments relationship.primaryjoin and relationship.secondaryjoin; “backref” is smart enough to know that these two arguments should also be “reversed” when generating the opposite side.

Specifying Backref Arguments

Lots of other arguments for a “backref” are not implicit, and include arguments like relationship.lazy, relationship.remote_side, relationship.cascade and relationship.cascade_backrefs. For this case we use the backref() function in place of a string; this will store a specific set of arguments that will be transferred to the new relationship() when generated:

  1. # <other imports>
  2. from sqlalchemy.orm import backref
  3. class User(Base):
  4. __tablename__ = "user"
  5. id = mapped_column(Integer, primary_key=True)
  6. name = mapped_column(String)
  7. addresses = relationship(
  8. "Address",
  9. backref=backref("user", lazy="joined"),
  10. )

Where above, we placed a lazy="joined" directive only on the Address.user side, indicating that when a query against Address is made, a join to the User entity should be made automatically which will populate the .user attribute of each returned Address. The backref() function formatted the arguments we gave it into a form that is interpreted by the receiving relationship() as additional arguments to be applied to the new relationship it creates.