Composite Column Types

    A simple example represents pairs of Integer columns as a object, with attributes .x and .y. Using a dataclass, these attributes are defined with the corresponding int Python type:

    Non-dataclass forms are also accepted, but require additional methods to be implemented. For an example using a non-dataclass class, see the section .

    New in version 2.0: The composite() construct fully supports Python dataclasses including the ability to derive mapped column datatypes from the composite class.

    We will create a mapping to a table vertices, which represents two points as x1/y1 and x2/y2. The Point class is associated with the mapped columns using the construct.

    The example below illustrates the most modern form of composite() as used with a fully configuration. mapped_column() constructs representing each column are passed directly to , indicating zero or more aspects of the columns to be generated, in this case the names; the composite() construct derives the column types (in this case int, corresponding to ) from the dataclass directly:

    1. from sqlalchemy.orm import DeclarativeBase, Mapped
    2. from sqlalchemy.orm import composite, mapped_column
    3. class Base(DeclarativeBase):
    4. pass
    5. class Vertex(Base):
    6. __tablename__ = "vertices"
    7. id: Mapped[int] = mapped_column(primary_key=True)
    8. start: Mapped[Point] = composite(mapped_column("x1"), mapped_column("y1"))
    9. end: Mapped[Point] = composite(mapped_column("x2"), mapped_column("y2"))
    10. def __repr__(self):
    11. return f"Vertex(start={self.start}, end={self.end})"

    The above mapping would correspond to a CREATE TABLE statement as:

    1. >>> from sqlalchemy.schema import CreateTable
    2. >>> print(CreateTable(Vertex.__table__))
    3. CREATE TABLE vertices (
    4. id INTEGER NOT NULL,
    5. x1 INTEGER NOT NULL,
    6. y1 INTEGER NOT NULL,
    7. x2 INTEGER NOT NULL,
    8. y2 INTEGER NOT NULL,
    9. PRIMARY KEY (id)
    10. )

    With a mapping as illustrated in the top section, we can work with the Vertex class, where the .start and .end attributes will transparently refer to the columns referred towards by the Point class, as well as with instances of the Vertex class, where the .start and .end attributes will refer to instances of the Point class. The x1, y1, x2, and y2 columns are handled transparently:

    • Persisting Point objects

      We can create a Vertex object, assign Point objects as members, and they will be persisted as expected:

      1. >>> v = Vertex(start=Point(3, 4), end=Point(5, 6))
      2. >>> session.add(v)
      3. >>> session.commit()
      4. BEGIN (implicit)
      5. INSERT INTO vertices (x1, y1, x2, y2) VALUES (?, ?, ?, ?)
      6. [generated in ...] (3, 4, 5, 6)
      7. COMMIT
    • Selecting Point objects as columns

      will allow the Vertex.start and Vertex.end attributes to behave like a single SQL expression to as much an extent as possible when using the ORM Session (including the legacy object) to select Point objects:

      1. >>> stmt = select(Vertex.start, Vertex.end)
      2. >>> session.execute(stmt).all()
      3. SELECT vertices.x1, vertices.y1, vertices.x2, vertices.y2
      4. FROM vertices
      5. [...] ()
      6. [(Point(x=3, y=4), Point(x=5, y=6))]
    • Comparing Point objects in SQL expressions

      The Vertex.start and Vertex.end attributes may be used in WHERE criteria and similar, using ad-hoc Point objects for comparisons:

      New in version 2.0: composite() constructs now support “ordering” comparisons such as <, >=, and similar, in addition to the already-present support for ==, !=.

      Tip

      The “ordering” comparison above using the “less than” operator (<) as well as the “equality” comparison using ==, when used to generate SQL expressions, are implemented by the Comparator class, and don’t make use of the comparison methods on the composite class itself, e.g. the __lt__() or __eq__() methods. From this it follows that the Point dataclass above also need not implement the dataclasses order=True parameter for the above SQL operations to work. The section contains background on how to customize the comparison operations.

    • Updating Point objects on Vertex Instances

      By default, the Point object must be replaced by a new object for changes to be detected:

      1. >>> v1 = session.scalars(select(Vertex)).one()
      2. SELECT vertices.id, vertices.x1, vertices.y1, vertices.x2, vertices.y2
      3. FROM vertices
      4. [...] ()
      5. >>> v1.end = Point(x=10, y=14)
      6. UPDATE vertices SET x2=?, y2=? WHERE vertices.id = ?
      7. [...] (10, 14, 1)
      8. COMMIT

      In order to allow in place changes on the composite object, the Mutation Tracking extension must be used. See the section for examples.

    Other mapping forms for composites

    The construct may be passed the relevant columns using a mapped_column() construct, a , or the string name of an existing mapped column. The following examples illustrate an equvalent mapping as that of the main section above.

    • Map columns directly, then pass to composite

      ``` from sqlalchemy import Integer from sqlalchemy.orm import mapped_column, composite

    1. class Vertex(Base):
    2. __tablename__ = "vertices"
    3. id = mapped_column(Integer, primary_key=True)
    4. x1 = mapped_column(Integer)
    5. y1 = mapped_column(Integer)
    6. x2 = mapped_column(Integer)
    7. y2 = mapped_column(Integer)
    8. start = composite(Point, x1, y1)
    9. end = composite(Point, x2, y2)
    10. ```
    • Map columns directly, pass attribute names to composite

      We can write the same example above using more annotated forms where we have the option to pass attribute names to composite() instead of full column constructs:

      ``` from sqlalchemy.orm import mapped_column, composite, Mapped

    1. class Vertex(Base):
    2. __tablename__ = "vertices"
    3. id: Mapped[int] = mapped_column(primary_key=True)
    4. x1: Mapped[int]
    5. y1: Mapped[int]
    6. x2: Mapped[int]
    7. y2: Mapped[int]
    8. start: Mapped[Point] = composite("x1", "y1")
    9. end: Mapped[Point] = composite("x2", "y2")
    10. ```
    • Imperative mapping and imperative table

      When using or fully imperative mappings, we have access to objects directly. These may be passed to composite() as well, as in the imperative example below:

      1. mapper_registry.map_imperatively(
      2. Vertex,
      3. vertices_table,
      4. properties={
      5. "start": composite(Point, vertices_table.c.x1, vertices_table.c.y1),
      6. "end": composite(Point, vertices_table.c.x2, vertices_table.c.y2),
      7. },
      8. )

    If not using a dataclass, the requirements for the custom datatype class are that it have a constructor which accepts positional arguments corresponding to its column format, and also provides a method __composite_values__() which returns the state of the object as a list or tuple, in order of its column-based attributes. It also should supply adequate __eq__() and __ne__() methods which test the equality of two instances.

    To illustrate the equivalent Point class from the main section not using a dataclass:

    Usage with composite() then proceeds where the columns to be associated with the Point class must also be declared with explicit types, using one of the forms at .

    Tracking In-Place Mutations on Composites

    In-place changes to an existing composite value are not tracked automatically. Instead, the composite class needs to provide events to its parent object explicitly. This task is largely automated via the usage of the mixin, which uses events to associate each user-defined composite object with all parent associations. Please see the example in Establishing Mutability on Composites.

    The “equals” comparison operation by default produces an AND of all corresponding columns equated to one another. This can be changed using the comparator_factory argument to composite(), where we specify a custom class to define existing or new operations. Below we illustrate the “greater than” operator, implementing the same expression that the base “greater than” does:

    1. import dataclasses
    2. from sqlalchemy.orm import composite
    3. from sqlalchemy.orm import CompositeProperty
    4. from sqlalchemy.orm import DeclarativeBase
    5. from sqlalchemy.orm import Mapped
    6. from sqlalchemy.orm import mapped_column
    7. from sqlalchemy.sql import and_
    8. @dataclasses.dataclass
    9. class Point:
    10. x: int
    11. y: int
    12. class PointComparator(CompositeProperty.Comparator):
    13. def __gt__(self, other):
    14. """redefine the 'greater than' operation"""
    15. return and_(
    16. *[
    17. a > b
    18. for a, b in zip(
    19. self.__clause_element__().clauses,
    20. dataclasses.astuple(other),
    21. )
    22. ]
    23. )
    24. class Base(DeclarativeBase):
    25. pass
    26. class Vertex(Base):
    27. __tablename__ = "vertices"
    28. id: Mapped[int] = mapped_column(primary_key=True)
    29. start: Mapped[Point] = composite(
    30. mapped_column("x1"), mapped_column("y1"), comparator_factory=PointComparator
    31. )
    32. end: Mapped[Point] = composite(

    Since Point is a dataclass, we may make use of dataclasses.astuple() to get a tuple form of Point instances.

    The custom comparator then returns the appropriate SQL expression:

    1. >>> print(Vertex.start > Point(5, 6))
    2. vertices.x1 > :x1_1 AND vertices.y1 > :y1_1

    Nesting Composites

    Composite objects can be defined to work in simple nested schemes, by redefining behaviors within the composite class to work as desired, then mapping the composite class to the full length of individual columns normally. This requires that additional methods to move between the “nested” and “flat” forms are defined.

    Below we reorganize the Vertex class to itself be a composite object which refers to Point objects. Vertex and Point can be dataclasses, however we will add a custom construction method to Vertex that can be used to create new Vertex objects given four column values, which will will arbitrarily name _generate() and define as a classmethod so that we can make new Vertex objects by passing values to the Vertex._generate() method.

    We will also implement the __composite_values__() method, which is a fixed name recognized by the construct (introduced previously at Using Legacy Non-Dataclasses) that indicates a standard way of receiving the object as a flat tuple of column values, which in this case will supersede the usual dataclass-oriented methodology.

    With our custom _generate() constructor and __composite_values__() serializer method, we can now move between a flat tuple of columns and Vertex objects that contain Point instances. The Vertex._generate method is passed as the first argument to the construct as the source of new Vertex instances, and the __composite_values__() method will be used implicitly by composite().

    For the purposes of the example, the Vertex composite is then mapped to a class called HasVertex, which is where the containing the four source columns ultimately resides:

    1. import dataclasses
    2. from sqlalchemy.orm import composite
    3. from sqlalchemy.orm import DeclarativeBase
    4. from sqlalchemy.orm import Mapped
    5. from sqlalchemy.orm import mapped_column
    6. @dataclasses.dataclass
    7. class Point:
    8. x: int
    9. y: int
    10. @dataclasses.dataclass
    11. class Vertex:
    12. start: Point
    13. end: Point
    14. @classmethod
    15. def _generate(self, x1, y1, x2, y2):
    16. """generate a Vertex from a row"""
    17. return Vertex(Point(x1, y1), Point(x2, y2))
    18. def __composite_values__(self):
    19. """generate a row from a Vertex"""
    20. return dataclasses.astuple(self.start) + dataclasses.astuple(self.end)
    21. class Base(DeclarativeBase):
    22. pass
    23. class HasVertex(Base):
    24. __tablename__ = "has_vertex"
    25. id: Mapped[int] = mapped_column(primary_key=True)
    26. x1: Mapped[int]
    27. y1: Mapped[int]
    28. x2: Mapped[int]
    29. y2: Mapped[int]
    30. vertex: Mapped[Vertex] = composite(Vertex._generate, "x1", "y1", "x2", "y2")

    The above mapping can then be used in terms of HasVertex, Vertex, and Point:

    1. hv = HasVertex(vertex=Vertex(Point(1, 2), Point(3, 4)))
    2. session.add(hv)
    3. session.commit()
    4. stmt = select(HasVertex).where(HasVertex.vertex == Vertex(Point(1, 2), Point(3, 4)))
    5. hv = session.scalars(stmt).first()
    6. print(hv.vertex.start)
    7. print(hv.vertex.end)

    Return a composite column-based property for use with a Mapper.

    See the mapping documentation section for a full usage example.

    The MapperProperty returned by is the Composite.

    • Parameters:

      • class_ – The “composite type” class, or any classmethod or callable which will produce a new instance of the composite object given the column values in order.

      • *attrs

        List of elements to be mapped, which may include:

        • objects

        • mapped_column() constructs

        • string names of other attributes on the mapped class, which may be any other SQL or object-mapped attribute. This can for example allow a composite that refers to a many-to-one relationship

      • active_history=False – When True, indicates that the “previous” value for a scalar attribute should be loaded when replaced, if not already loaded. See the same flag on .

      • group – A group name for this property when marked as deferred.

      • deferred – When True, the column property is “deferred”, meaning that it does not load immediately, and is instead loaded when the attribute is first accessed on an instance. See also deferred().

      • comparator_factory – a class which extends Comparator which provides custom SQL clause generation for comparison operations.

      • doc – optional string that will be applied as the doc on the class-bound descriptor.

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

      • init – Specific to Declarative Dataclass Mapping, specifies if the mapped attribute should be part of the __init__() method as generated by the dataclass process.

      • repr – Specific to , specifies if the mapped attribute should be part of the __repr__() method as generated by the dataclass process.

      • default_factory – Specific to Declarative Dataclass Mapping, specifies a default-value generation function that will take place as part of the __init__() method as generated by the dataclass process.

      • compare

        Specific to , indicates if this field should be included in comparison operations when generating the __eq__() and methods for the mapped class.