Загрузка иерархий наследования¶

Использование with_polymorphic¶

В следующих разделах мы будем рассматривать примеры Employee / Engineer / Manager, приведенные в Сопоставление иерархий наследования классов.

Обычно, когда Query указывает базовый класс иерархии наследования, запрашиваются только столбцы, локальные для этого базового класса:

session.query(Employee).all()

Выше, как для одиночного, так и для объединенного наследования таблиц, в SELECT будут присутствовать только столбцы, локальные для Employee. Мы можем получить обратно экземпляры Engineer или Manager, однако у них не будут загружены дополнительные атрибуты, пока мы не обратимся к ним впервые, и тогда будет выдана ленивая загрузка.

Аналогично, если бы мы хотели сослаться на столбцы, отображенные на Engineer или Manager в нашем запросе к Employee, эти столбцы недоступны напрямую ни в случае наследования по одной, ни по объединенной таблице, поскольку сущность Employee не ссылается на эти столбцы (обратите внимание, что для наследования по одной таблице это обычное явление, если используется Declarative, но не для классического отображения).

Чтобы решить обе эти проблемы, функция with_polymorphic() предоставляет специальный объект AliasedClass, который представляет диапазон столбцов между подклассами. Этот объект можно использовать в Query, как и любой другой псевдоним. При запросе он представляет все столбцы, присутствующие в указанных классах:

from sqlalchemy.orm import with_polymorphic

eng_plus_manager = with_polymorphic(Employee, [Engineer, Manager])

query = session.query(eng_plus_manager)

Если бы приведенное выше отображение использовало наследование объединенных таблиц, оператор SELECT для этого был бы следующим:

query.all()
SELECT
    employee.id AS employee_id,
    engineer.id AS engineer_id,
    manager.id AS manager_id,
    employee.name AS employee_name,
    employee.type AS employee_type,
    engineer.engineer_info AS engineer_engineer_info,
    manager.manager_data AS manager_manager_data
FROM
    employee
    LEFT OUTER JOIN engineer ON employee.id = engineer.id
    LEFT OUTER JOIN manager ON employee.id = manager.id
[]

Там, где указано выше, включены дополнительные таблицы / столбцы для «инженера» и «менеджера». Аналогичное поведение происходит в случае наследования одной таблицы.

with_polymorphic() принимает один класс или маппер, список классов/мапперов или строку '*' для указания всех подклассов:

# include columns for Engineer
entity = with_polymorphic(Employee, Engineer)

# include columns for Engineer, Manager
entity = with_polymorphic(Employee, [Engineer, Manager])

# include columns for all mapped subclasses
entity = with_polymorphic(Employee, "*")

engineer_employee = with_polymorphic(Employee, [Engineer], aliased=True)
manager_employee = with_polymorphic(Employee, [Manager], aliased=True)

q = s.query(engineer_employee, manager_employee).join(
    manager_employee,
    and_(
        engineer_employee.id > manager_employee.id,
        engineer_employee.name == manager_employee.name,
    ),
)
q.all()
SELECT
    anon_1.employee_id AS anon_1_employee_id,
    anon_1.employee_name AS anon_1_employee_name,
    anon_1.employee_type AS anon_1_employee_type,
    anon_1.engineer_id AS anon_1_engineer_id,
    anon_1.engineer_engineer_name AS anon_1_engineer_engineer_name,
    anon_2.employee_id AS anon_2_employee_id,
    anon_2.employee_name AS anon_2_employee_name,
    anon_2.employee_type AS anon_2_employee_type,
    anon_2.manager_id AS anon_2_manager_id,
    anon_2.manager_manager_name AS anon_2_manager_manager_name
FROM (
    SELECT
        employee.id AS employee_id,
        employee.name AS employee_name,
        employee.type AS employee_type,
        engineer.id AS engineer_id,
        engineer.engineer_name AS engineer_engineer_name
    FROM employee
    LEFT OUTER JOIN engineer ON employee.id = engineer.id
) AS anon_1
JOIN (
    SELECT
        employee.id AS employee_id,
        employee.name AS employee_name,
        employee.type AS employee_type,
        manager.id AS manager_id,
         manager.manager_name AS manager_manager_name
    FROM employee
    LEFT OUTER JOIN manager ON employee.id = manager.id
) AS anon_2
ON anon_1.employee_id > anon_2.employee_id
AND anon_1.employee_name = anon_2.employee_name

engineer_employee = with_polymorphic(Employee, [Engineer], flat=True)
manager_employee = with_polymorphic(Employee, [Manager], flat=True)

q = s.query(engineer_employee, manager_employee).join(
    manager_employee,
    and_(
        engineer_employee.id > manager_employee.id,
        engineer_employee.name == manager_employee.name,
    ),
)
q.all()
SELECT
    employee_1.id AS employee_1_id,
    employee_1.name AS employee_1_name,
    employee_1.type AS employee_1_type,
    engineer_1.id AS engineer_1_id,
    engineer_1.engineer_name AS engineer_1_engineer_name,
    employee_2.id AS employee_2_id,
    employee_2.name AS employee_2_name,
    employee_2.type AS employee_2_type,
    manager_1.id AS manager_1_id,
    manager_1.manager_name AS manager_1_manager_name
FROM employee AS employee_1
LEFT OUTER JOIN engineer AS engineer_1
ON employee_1.id = engineer_1.id
JOIN (
    employee AS employee_2
    LEFT OUTER JOIN manager AS manager_1
    ON employee_2.id = manager_1.id
)
ON employee_1.id > employee_2.id
AND employee_1.name = employee_2.name

eng_plus_manager = with_polymorphic(Employee, [Engineer, Manager])
query = session.query(eng_plus_manager).filter(
    or_(
        eng_plus_manager.Engineer.engineer_info == "x",
        eng_plus_manager.Manager.manager_data == "y",
    )
)

query.all()
SELECT
    employee.id AS employee_id,
    engineer.id AS engineer_id,
    manager.id AS manager_id,
    employee.name AS employee_name,
    employee.type AS employee_type,
    engineer.engineer_info AS engineer_engineer_info,
    manager.manager_data AS manager_manager_data
FROM
    employee
    LEFT OUTER JOIN engineer ON employee.id = engineer.id
    LEFT OUTER JOIN manager ON employee.id = manager.id
WHERE
  engineer.engineer_info=? OR
  manager.manager_data=?
['x', 'y']

class Employee(Base):
    __tablename__ = "employee"
    id = Column(Integer, primary_key=True)
    name = Column(String(50))
    type = Column(String(50))

    __mapper_args__ = {
        "polymorphic_identity": "employee",
        "polymorphic_on": type,
        "with_polymorphic": "*",
    }

class Engineer(Employee):
    __tablename__ = "engineer"
    id = Column(Integer, ForeignKey("employee.id"), primary_key=True)
    engineer_info = Column(String(50))
    __mapper_args__ = {"polymorphic_identity": "engineer", "polymorphic_load": "inline"}


class Manager(Employee):
    __tablename__ = "manager"
    id = Column(Integer, ForeignKey("employee.id"), primary_key=True)
    manager_data = Column(String(50))
    __mapper_args__ = {"polymorphic_identity": "manager", "polymorphic_load": "inline"}

session.query(Employee).with_polymorphic([Engineer, Manager]).filter(
    or_(Engineer.engineer_info == "w", Manager.manager_data == "q")
)

Загрузка полиморфного селектина¶

Альтернативой использованию семейства функций with_polymorphic() для «нетерпеливой» загрузки дополнительных подклассов на отображении наследования, в основном при использовании наследования объединенных таблиц, является использование полиморфной загрузки «selectin». Это функция ускоренной загрузки, которая работает аналогично функции Выберите загрузку IN загрузки отношений. Учитывая наш пример отображения, мы можем указать загрузке Employee выдавать дополнительный SELECT для каждого подкласса, используя опцию загрузчика selectin_polymorphic():

from sqlalchemy.orm import selectin_polymorphic

query = session.query(Employee).options(
    selectin_polymorphic(Employee, [Manager, Engineer])
)

При выполнении приведенного выше запроса будут выданы два дополнительных оператора SELECT:

query.all()
SELECT
    employee.id AS employee_id,
    employee.name AS employee_name,
    employee.type AS employee_type
FROM employee
()

SELECT
    engineer.id AS engineer_id,
    employee.id AS employee_id,
    employee.type AS employee_type,
    engineer.engineer_name AS engineer_engineer_name
FROM employee JOIN engineer ON employee.id = engineer.id
WHERE employee.id IN (?, ?) ORDER BY employee.id
(1, 2)

SELECT
    manager.id AS manager_id,
    employee.id AS employee_id,
    employee.type AS employee_type,
    manager.manager_name AS manager_manager_name
FROM employee JOIN manager ON employee.id = manager.id
WHERE employee.id IN (?) ORDER BY employee.id
(3,)

Мы можем аналогичным образом установить вышеуказанный стиль загрузки по умолчанию, указав параметр mapper.polymorphic_load, используя значение "selectin" на основе каждого подкласса:

class Employee(Base):
    __tablename__ = "employee"
    id = Column(Integer, primary_key=True)
    name = Column(String(50))
    type = Column(String(50))

    __mapper_args__ = {"polymorphic_identity": "employee", "polymorphic_on": type}


class Engineer(Employee):
    __tablename__ = "engineer"
    id = Column(Integer, ForeignKey("employee.id"), primary_key=True)
    engineer_name = Column(String(30))

    __mapper_args__ = {
        "polymorphic_load": "selectin",
        "polymorphic_identity": "engineer",
    }


class Manager(Employee):
    __tablename__ = "manager"
    id = Column(Integer, ForeignKey("employee.id"), primary_key=True)
    manager_name = Column(String(30))

    __mapper_args__ = {
        "polymorphic_load": "selectin",
        "polymorphic_identity": "manager",
    }

В отличие от использования with_polymorphic(), при использовании стиля загрузки selectin_polymorphic() у нас нет возможности ссылаться на объекты Engineer или Manager в нашем основном запросе в качестве фильтра, порядка по или других критериев, поскольку эти объекты не присутствуют в исходном запросе, который используется для поиска результатов. Однако мы можем применить опции загрузчика, которые применяются к Engineer или Manager, которые вступят в силу, когда будет выдан вторичный SELECT. Ниже мы предположим, что Manager имеет дополнительное отношение Manager.paperwork, которое мы также хотим нетерпеливо загрузить. Мы можем использовать любой тип ускоренной загрузки, например, объединенную ускоренную загрузку с помощью функции joinedload():

from sqlalchemy.orm import joinedload
from sqlalchemy.orm import selectin_polymorphic

query = session.query(Employee).options(
    selectin_polymorphic(Employee, [Manager, Engineer]), joinedload(Manager.paperwork)
)

Используя приведенный выше запрос, мы получим три оператора SELECT, однако один из них будет иметь значение Manager:

SELECT
    manager.id AS manager_id,
    employee.id AS employee_id,
    employee.type AS employee_type,
    manager.manager_name AS manager_manager_name,
    paperwork_1.id AS paperwork_1_id,
    paperwork_1.manager_id AS paperwork_1_manager_id,
    paperwork_1.data AS paperwork_1_data
FROM employee JOIN manager ON employee.id = manager.id
LEFT OUTER JOIN paperwork AS paperwork_1
ON manager.id = paperwork_1.manager_id
WHERE employee.id IN (?) ORDER BY employee.id
(3,)

Обратите внимание, что полиморфная загрузка selectin имеет те же предостережения, что и загрузка отношений selectin; для сущностей, использующих составной первичный ключ, используемая база данных должна поддерживать кортежи с «IN», в настоящее время известно, что они работают с MySQL и PostgreSQL.

# use "Employee" example from the enclosing section


class Manager(Employee):
    __tablename__ = "manager"
    id = Column(Integer, ForeignKey("employee.id"), primary_key=True)
    manager_name = Column(String(30))

    __mapper_args__ = {
        "polymorphic_load": "selectin",
        "polymorphic_identity": "manager",
    }


class VicePresident(Manager):
    vp_info = Column(String(30))

    __mapper_args__ = {"polymorphic_load": "inline", "polymorphic_identity": "vp"}

SELECT employee.id AS employee_id, employee.name AS employee_name,
       employee.type AS employee_type
FROM employee
)

SELECT manager.id AS manager_id, employee.id AS employee_id,
       employee.type AS employee_type,
       manager.manager_name AS manager_manager_name,
       manager.vp_info AS manager_vp_info
FROM employee JOIN manager ON employee.id = manager.id
WHERE employee.id IN (?) ORDER BY employee.id
(1,)

from sqlalchemy.orm import with_polymorphic, selectin_polymorphic

manager_poly = with_polymorphic(Manager, [VicePresident])

s.query(Employee).options(selectin_polymorphic(Employee, [manager_poly])).all()

Обращение к конкретным подтипам отношений¶

Атрибуты отображения, соответствующие relationship(), используются в запросах для обозначения связи между двумя отображениями. Обычно это используется для ссылки на relationship() в Query.join(), а также в опциях загрузчика, таких как joinedload(). При использовании relationship(), когда целевой класс является иерархией наследования, API позволяет, чтобы присоединение, нетерпеливая загрузка или другая связь была нацелена на определенный подкласс, псевдокласс или with_polymorphic() псевдоним этой иерархии классов, а не на класс, непосредственно нацеленный relationship().

Метод of_type() позволяет строить объединения по relationship() путям, сужая критерий до конкретных производных псевдонимов или подклассов. Предположим, что таблица employees представляет коллекцию сотрудников, которые связаны с объектом Company. Мы добавим столбец company_id к таблице employees и новую таблицу companies:

class Company(Base):
    __tablename__ = "company"
    id = Column(Integer, primary_key=True)
    name = Column(String(50))
    employees = relationship("Employee", backref="company")


class Employee(Base):
    __tablename__ = "employee"
    id = Column(Integer, primary_key=True)
    type = Column(String(20))
    company_id = Column(Integer, ForeignKey("company.id"))
    __mapper_args__ = {
        "polymorphic_on": type,
        "polymorphic_identity": "employee",
    }


class Engineer(Employee):
    __tablename__ = "engineer"
    id = Column(Integer, ForeignKey("employee.id"), primary_key=True)
    engineer_info = Column(String(50))
    __mapper_args__ = {"polymorphic_identity": "engineer"}


class Manager(Employee):
    __tablename__ = "manager"
    id = Column(Integer, ForeignKey("employee.id"), primary_key=True)
    manager_data = Column(String(50))
    __mapper_args__ = {"polymorphic_identity": "manager"}

При запросе из Company на отношение Employee, метод Query.join(), а также операторы PropComparator.any() и PropComparator.has() создадут объединение от company к employee, не включая engineer или manager в смесь. Если мы хотим иметь критерий, направленный конкретно на класс Engineer, мы можем указать этим методам присоединиться или выполнить подзапрос к набору столбцов, представляющих подкласс, используя оператор PropComparator.of_type():

session.query(Company).join(Company.employees.of_type(Engineer)).filter(
    Engineer.engineer_info == "someinfo"
)

Аналогично, для присоединения из Company к полиморфной сущности, включающей столбцы Engineer и Manager:

manager_and_engineer = with_polymorphic(Employee, [Manager, Engineer])

session.query(Company).join(Company.employees.of_type(manager_and_engineer)).filter(
    or_(
        manager_and_engineer.Engineer.engineer_info == "someinfo",
        manager_and_engineer.Manager.manager_data == "somedata",
    )
)

Операторы PropComparator.any() и PropComparator.has() также могут использоваться с of_type(), например, когда встроенный критерий находится в терминах подкласса:

session.query(Company).filter(
    Company.employees.of_type(Engineer).any(Engineer.engineer_info == "someinfo")
).all()

session.query(Company).\
    options(
        subqueryload(Company.employees.of_type(Engineer)).
        subqueryload(Engineer.machines)
        )
    )

manager_and_engineer = with_polymorphic(Employee, [Manager, Engineer], flat=True)

session.query(Company).options(
    joinedload(Company.employees.of_type(manager_and_engineer))
)

session.query(Company).\
    options(
        joinedload(Company.employees.of_type(manager_and_engineer)).\
        subqueryload(manager_and_engineer.Engineer.computers)
        )
    )

Загрузка объектов с объединенным наследованием таблиц¶

При использовании наследования объединенных таблиц, если мы запросим конкретный подкласс, который представляет собой JOIN двух таблиц, как в нашем примере Engineer из раздела наследования, SQL будет выдан как join:

session.query(Engineer).all()

Приведенный выше запрос выдаст SQL вида:

SELECT employee.id AS employee_id,
    employee.name AS employee_name, employee.type AS employee_type,
    engineer.name AS engineer_name
FROM employee JOIN engineer
ON employee.id = engineer.id

Затем мы получим обратно коллекцию объектов Engineer, которая будет содержать все столбцы из employee и engineer загруженных.

Однако, когда выдается Query против базового класса, поведение заключается в загрузке только из базовой таблицы:

session.query(Employee).all()

Выше, поведение по умолчанию будет заключаться в SELECT только из таблицы employee и не из любых «под» таблиц (engineer и manager, в наших предыдущих примерах):

SELECT employee.id AS employee_id,
    employee.name AS employee_name, employee.type AS employee_type
FROM employee
[]

После того, как коллекция объектов Employee была возвращена из запроса, и по мере запроса атрибутов у этих объектов Employee, которые представлены в дочерних таблицах engineer или manager, выполняется вторая загрузка для столбцов в соответствующей строке, если данные еще не были загружены. Таким образом, выше, после доступа к объектам, вы увидите дальнейший SQL, выданный по следующей схеме:

SELECT manager.id AS manager_id,
    manager.manager_data AS manager_manager_data
FROM manager
WHERE ? = manager.id
[5]
SELECT engineer.id AS engineer_id,
    engineer.engineer_info AS engineer_engineer_info
FROM engineer
WHERE ? = engineer.id
[2]

Функция with_polymorphic() и соответствующие параметры конфигурации позволяют нам вместо этого выдать JOIN, который будет условно загружать employee, engineer или manager, очень похоже на то, как соединенная нетерпеливая загрузка работает для отношений, устраняя необходимость во второй загрузке для каждого объекта:

from sqlalchemy.orm import with_polymorphic

eng_plus_manager = with_polymorphic(Employee, [Engineer, Manager])

query = session.query(eng_plus_manager)

Вышеприведенный запрос создает запрос, который соединяет таблицу employee с таблицами engineer и manager следующим образом:

query.all()
SELECT employee.id AS employee_id,
    engineer.id AS engineer_id,
    manager.id AS manager_id,
    employee.name AS employee_name,
    employee.type AS employee_type,
    engineer.engineer_info AS engineer_engineer_info,
    manager.manager_data AS manager_manager_data
FROM employee
    LEFT OUTER JOIN engineer
    ON employee.id = engineer.id
    LEFT OUTER JOIN manager
    ON employee.id = manager.id
[]

В разделе Использование with_polymorphic обсуждается функция with_polymorphic() и ее конфигурационные варианты.

Загрузка объектов с наследованием одной таблицы¶

В современном Declarative отображения с единственным наследованием создают объекты Column, которые отображаются только на подкласс и недоступны из суперкласса, даже если они присутствуют в одной таблице. В нашем примере из Наследование одной таблицы, отображение Manager, например, имело Column, указанное:

class Manager(Employee):
    manager_data = Column(String(50))

    __mapper_args__ = {"polymorphic_identity": "manager"}

Выше не было атрибута Employee.manager_data, хотя таблица employee имеет столбец manager_data. Запрос к Manager будет включать этот столбец в запрос, а также предложение IN для ограничения строк только объектами Manager:

session.query(Manager).all()
SELECT
    employee.id AS employee_id,
    employee.name AS employee_name,
    employee.type AS employee_type,
    employee.manager_data AS employee_manager_data
FROM employee
WHERE employee.type IN (?)

('manager',)

Однако, аналогично наследованию объединенных таблиц, запрос к Employee будет запрашивать только столбцы, сопоставленные с Employee:

session.query(Employee).all()
SELECT employee.id AS employee_id,
    employee.name AS employee_name,
    employee.type AS employee_type
FROM employee

Если мы получаем обратно экземпляр Manager из нашего результата, обращение к дополнительным столбцам, сопоставленным только с Manager, вызывает ленивую загрузку для этих столбцов, аналогично объединенному наследованию:

SELECT employee.manager_data AS employee_manager_data
FROM employee
WHERE employee.id = ? AND employee.type IN (?)

Функция with_polymorphic() выполняет ту же роль, что и объединенное наследование в случае одиночного наследования; она позволяет как загружать атрибуты подклассов, так и указывать подклассы в запросе, только без накладных расходов на использование OUTER JOIN:

employee_poly = with_polymorphic(Employee, "*")

q = session.query(employee_poly).filter(
    or_(employee_poly.name == "a", employee_poly.Manager.manager_data == "b")
)

Выше, наш запрос остается к одной таблице, однако мы можем ссылаться на столбцы, присутствующие в Manager или Engineer, используя пространство имен «polymorphic». Поскольку мы указали "*" для сущностей, оба Engineer и Manager будут загружены сразу. SQL будет выглядеть следующим образом:

q.all()
SELECT
    employee.id AS employee_id, employee.name AS employee_name,
    employee.type AS employee_type,
    employee.manager_data AS employee_manager_data,
    employee.engineer_info AS employee_engineer_info
FROM employee
WHERE employee.name = :name_1
OR employee.manager_data = :manager_data_1

Наследование API загрузки¶