API взаимоотношений¶

function sqlalchemy.orm.relationship(argument: Optional[_RelationshipArgumentType[Any]] = None, secondary: Optional[_RelationshipSecondaryArgument] = None, *, uselist: Optional[bool] = None, collection_class: Optional[Union[Type[Collection[Any]], Callable[[], Collection[Any]]]] = None, primaryjoin: Optional[_RelationshipJoinConditionArgument] = None, secondaryjoin: Optional[_RelationshipJoinConditionArgument] = None, back_populates: Optional[str] = None, order_by: _ORMOrderByArgument = False, backref: Optional[ORMBackrefArgument] = None, overlaps: Optional[str] = None, post_update: bool = False, cascade: str = 'save-update, merge', viewonly: bool = False, init: Union[_NoArg, bool] = _NoArg.NO_ARG, repr: Union[_NoArg, bool] = _NoArg.NO_ARG, default: Union[_NoArg, _T] = _NoArg.NO_ARG, default_factory: Union[_NoArg, Callable[[], _T]] = _NoArg.NO_ARG, compare: Union[_NoArg, bool] = _NoArg.NO_ARG, kw_only: Union[_NoArg, bool] = _NoArg.NO_ARG, lazy: _LazyLoadArgumentType = 'select', passive_deletes: Union[Literal['all'], bool] = False, passive_updates: bool = True, active_history: bool = False, enable_typechecks: bool = True, foreign_keys: Optional[_ORMColCollectionArgument] = None, remote_side: Optional[_ORMColCollectionArgument] = None, join_depth: Optional[int] = None, comparator_factory: Optional[Type[RelationshipProperty.Comparator[Any]]] = None, single_parent: bool = False, innerjoin: bool = False, distinct_target_key: Optional[bool] = None, load_on_pending: bool = False, query_class: Optional[Type[Query[Any]]] = None, info: Optional[_InfoType] = None, omit_join: Literal[None, False] = None, sync_backref: Optional[bool] = None, **kw: Any) → Relationship[Any]¶

Обеспечить связь между двумя сопоставленными классами.

Это соответствует отношениям «родитель-ребенок» или ассоциативной таблице. Построенный класс является экземпляром Relationship.

См.также

Работа с объектами, связанными с ORM - учебное введение в relationship() в Унифицированный учебник по SQLAlchemy

Конфигурация отношений - описательная документация

Параметры:

• argument – Этот параметр указывает на класс, который должен быть связан. Он принимает несколько форм, включая прямую ссылку на сам целевой класс, экземпляр Mapper для целевого класса, Python callable / lambda, которая вернет ссылку на класс или Mapper при вызове, и, наконец, строковое имя класса, которое будет разрешено из registry в использовании, чтобы найти класс, например:: class SomeClass(Base): # … related = relationship(«RelatedClass») В конструкции relationship.argument можно также полностью опустить relationship(), а вместо этого поместить в левую часть аннотацию Mapped, которая должна включать тип коллекции Python, если ожидается, что отношение будет коллекцией, например:: class SomeClass(Base): # … related_items: Mapped[List[«RelatedItem»]] = relationship() Или для отношений «многие-к-одному» или «один-к-одному»:: class SomeClass(Base): # … related_item: Mapped[«RelatedItem»] = relationship() … seealso:: Определение сопоставленных свойств с помощью декларативного метода - более подробно о конфигурации отношений при использовании Declarative.

• secondary – Для отношения «многие-ко-многим» указывает промежуточную таблицу и обычно является экземпляром Table. В менее распространенных случаях аргумент может быть указан как конструкция Alias или даже как конструкция Join. relationship.secondary также может быть передан в виде вызываемой функции, которая оценивается при инициализации картографа. При использовании Declarative это также может быть строковый аргумент, указывающий имя Table, которое присутствует в коллекции MetaData, связанной с родительским отображаемым Table. … warning:: Если аргумент передается как Python-выражаемая строка, то он интерпретируется с помощью функции Python eval(). НЕ ПЕРЕДАВАЙТЕ В ЭТУ СТРОКУ НЕДОВЕРЕННЫЕ ВХОДНЫЕ ДАННЫЕ. Подробнее о декларативной оценке аргументов Оценка аргументов в пользу отношений смотрите раздел relationship(). Аргумент с ключевым словом relationship.secondary обычно применяется в том случае, когда промежуточная Table не выражена иным образом в каком-либо прямом отображении класса. Если «вторичная» таблица также явно отображена в другом месте (например, как в Объект ассоциации), следует рассмотреть возможность применения флага relationship.viewonly, чтобы эта relationship() не использовалась для операций персистентного хранения, которые могут конфликтовать с операциями шаблона объекта ассоциации. … см. также:: Многие ко многим - Эталонный пример «многие ко многим». Отношения «многие-ко-многим» с самореференцией - Специфика использования many-to-many в самореферентном случае. Настройка отношений «многие-ко-многим - Дополнительные опции при использовании Declarative. Объект ассоциации - альтернатива relationship.secondary при составлении отношений ассоциативных таблиц, позволяющая указывать дополнительные атрибуты ассоциативной таблицы. Составные «вторичные» соединения - менее распространенный шаблон, который в некоторых случаях позволяет использовать сложные условия relationship() SQL.

• active_history=False – Когда True, указывает, что при замене «предыдущее» значение для ссылки «многие-к-одному» должно быть загружено, если оно еще не загружено. Обычно логика отслеживания истории для простых ссылок типа «многие-к-одному» должна знать о «новом» значении только для того, чтобы выполнить промывку. Этот флаг доступен для приложений, использующих get_history(), которым также необходимо знать «предыдущее» значение атрибута.

• backref – Ссылка на строковое имя отношения или конструкцию backref(), которая будет использована для автоматической генерации нового relationship() на связанном классе, который затем ссылается на этот класс, используя двунаправленную конфигурацию relationship.back_populates. В современном Python явное использование relationship() с relationship.back_populates должно быть предпочтительнее, поскольку оно более надежно с точки зрения конфигурации маппера, а также более концептуально просто. Это также позволяет интегрироваться с новыми возможностями типизации PEP 484, появившимися в SQLAlchemy 2.0, что невозможно при использовании динамически генерируемых атрибутов. … seealso:: Использование унаследованного параметра отношения „backref“ - заметки по использованию relationship.backref Работа с объектами, связанными с ORM - в Унифицированный учебник по SQLAlchemy представлен обзор конфигурации двунаправленных отношений и поведения при использовании relationship.back_populates backref() - позволяет контролировать relationship() конфигурацию при использовании relationship.backref.

• back_populates – Указывает имя relationship() на связанном классе, который будет синхронизирован с этим классом. Обычно предполагается, что relationship() на связанном классе также ссылается на этот класс. Это позволяет объектам по обе стороны каждого relationship() синхронизировать изменения состояния в Python, а также дает указания процессу unit of work flush о том, как должны сохраняться изменения в рамках этих отношений. … см. также:: Работа с объектами, связанными с ORM - в Унифицированный учебник по SQLAlchemy представлен обзор конфигурации и поведения двунаправленных отношений. Основные модели взаимоотношений - включает множество примеров relationship.back_populates. relationship.backref - унаследованная форма, позволяющая более лаконично конфигурировать, но не поддерживающая явную типизацию

• overlaps – Строковое имя или ограниченный запятыми набор имен других отношений на этом, потомковом или целевом картографе, с которыми это отношение может записывать в одни и те же внешние ключи при сохранении. Единственный эффект, который это дает, - устранение предупреждения о том, что данное отношение будет конфликтовать с другим при сохранении. Это используется для таких отношений, которые действительно могут конфликтовать друг с другом при записи, но приложение будет гарантировать, что таких конфликтов не произойдет. … версия добавлена:: 1.4 .. seealso:: отношение X скопирует столбец Q в столбец P, что противоречит отношению(ям): „Y“ - пример использования

• cascade – Список правил каскадирования, разделенный запятыми, который определяет, как операции сеанса должны «каскадироваться» от родителя к ребенку. По умолчанию это значение равно False, что означает, что должен использоваться каскад по умолчанию - по умолчанию это "save-update, merge". Доступны следующие каскады: save-update, merge, expunge, delete, delete-orphan и refresh-expire. Дополнительная опция all является сокращением для "save-update, merge, refresh-expire, expunge, delete" и часто используется, как и "all, delete-orphan", для указания на то, что связанные объекты должны следовать за родительским объектом во всех случаях и удаляться при деассоциации. … см. также:: Каскады - Полная информация о каждом из доступных вариантов каскадирования.

• cascade_backrefs=False – Legacy; этот флаг всегда False. … versionchanged:: 2.0 Функциональность «cascade_backrefs» была удалена.

• collection_class – Класс или вызываемый объект, который возвращает новый объект, содержащий список. будет использоваться вместо обычного списка для хранения элементов. … seealso:: Настройка доступа к коллекции - Вводная документация и примеры.

• comparator_factory – Класс, расширяющий Comparator, который обеспечивает генерацию пользовательских SQL-клауз для операций сравнения. … см. также:: PropComparator - некоторые подробности переопределения компараторов на этом уровне. Настройка оператора - краткое введение в эту возможность.

• distinct_target_key=None – Укажите, следует ли при нетерпеливой загрузке «подзапроса» применять ключевое слово DISTINCT к самому внутреннему оператору SELECT. Если оставить значение None, то ключевое слово DISTINCT будет применяться в тех случаях, когда целевые столбцы не составляют полный первичный ключ целевой таблицы. При установке значения True ключевое слово DISTINCT применяется к внутреннему SELECT безусловно. Может оказаться желательным установить этот флаг в False, если DISTINCT снижает производительность внутреннего подзапроса больше, чем это может быть вызвано дублированием внутренних строк. … см. также:: Техники загрузки отношений - включает в себя введение в ускоренную загрузку подзапросов.

• doc – Docstring, который будет применен к результирующему дескриптору.

• foreign_keys – Список столбцов, которые должны использоваться в качестве столбцов «внешнего ключа», или столбцов, ссылающихся на значение в удаленном столбце, в контексте условия relationship() данного объекта relationship.primaryjoin. То есть, если условием relationship.primaryjoin данного relationship() является a.id == b.a_id, а значения в b.a_id должны присутствовать в a.id, то столбцом «внешнего ключа» данного relationship() является b.a_id. В обычных случаях параметр relationship.foreign_keys не требуется. relationship() автоматически определяет, какие столбцы в условии relationship.primaryjoin должны считаться столбцами «внешнего ключа», на основании тех объектов Column, которые указывают ForeignKey, или иным образом перечислены как ссылающиеся столбцы в конструкции ForeignKeyConstraint. relationship.foreign_keys необходим только в том случае, если: 1. Существует более одного способа построения соединения из локальной таблицы в удаленную таблицу, поскольку присутствует несколько ссылок на внешний ключ. Установка foreign_keys ограничит relationship() тем, что будут учитываться только те столбцы, которые указаны здесь как «иностранные». 2. В отображаемой таблице Table фактически отсутствуют конструкции ForeignKey или ForeignKeyConstraint, что часто связано с тем, что таблица была отражена из базы данных, не поддерживающей отражение внешних ключей (MySQL MyISAM). 3. Аргумент relationship.primaryjoin используется для построения нестандартного условия объединения, в котором используются столбцы или выражения, которые обычно не ссылаются на свой «родительский» столбец, например, условие объединения, выраженное сложным сравнением с помощью функции SQL. Конструкция relationship() будет выдавать информативные сообщения об ошибках, в которых предлагается использовать параметр relationship.foreign_keys при неоднозначном условии. В типичных случаях, если relationship() не вызывает никаких исключений, параметр relationship.foreign_keys обычно не нужен. relationship.foreign_keys также может быть передан в виде вызываемой функции, которая оценивается при инициализации картографа, и может быть передан в виде Python-выражаемой строки при использовании Declarative. … warning:: Если аргумент передается как Python-evaluable string, то он интерпретируется с помощью функции Python eval(). НЕ ПЕРЕДАВАЙТЕ В ЭТУ СТРОКУ НЕДОВЕРЕННЫЕ ДАННЫЕ. Подробнее о декларативной оценке аргументов relationship() см. в разделе Оценка аргументов в пользу отношений. … seealso:: Работа с несколькими путями присоединения Создание пользовательских иностранных условий foreign() - позволяет напрямую аннотировать «чужие» столбцы в relationship.primaryjoin условии.

• info – Необязательный словарь данных, который будет заполнен в атрибут MapperProperty.info данного объекта.

• innerjoin=False – Если True, то для соединения со смежными таблицами вместо внешнего соединения будет использоваться внутреннее соединение. Эта опция обычно используется для повышения производительности, так как внутренние соединения обычно работают лучше, чем внешние. Этот флаг может быть установлен в значение True, если отношение ссылается на объект по принципу «многие-к-одному» с использованием локальных внешних ключей, которые не являются нулевыми, или если ссылка «один-к-одному» или коллекция, которая гарантированно имеет одну или по крайней мере одну запись. Опция поддерживает те же опции «nested» и «unnested», что и флаг joinedload.innerjoin. Подробнее о вложенном и невложенном поведении см. в этом флаге. … seealso:: joinedload.innerjoin - опция, указанная в опции загрузчика, включая подробности о поведении вложенности. Какой тип загрузки использовать? - обсуждение некоторых деталей различных опций загрузчика.

• join_depth – Если не``None``, то целочисленное значение, указывающее, на сколько уровней вглубь должны присоединяться «жаждущие» загрузчики по самоссылающейся или циклической связи. Число учитывает, сколько раз один и тот же Mapper должен присутствовать в условии загрузки по определенной ветви соединения. Если оставить значение по умолчанию None, то нетерпеливые загрузчики будут останавливать цепочку, когда встретят тот же целевой мэппер, который уже находится выше в цепочке. Эта опция применима как к загрузчикам с присоединением, так и к загрузчикам с подзапросом. … см. также:: Настройка самовоспроизводящейся ускоренной загрузки - Вводная документация и примеры.

• lazy='select' – задает способ загрузки связанных элементов. Значение по умолчанию - select. Значения включают: * select - элементы должны загружаться лениво при первом обращении к свойству, используя отдельный оператор SELECT или выборку из карты идентификации для простых ссылок «многие к одному». * immediate - элементы должны загружаться по мере загрузки родительских свойств, используя отдельный оператор SELECT или выборку из карты идентификации для простых ссылок «многие-к-одному». * joined - элементы должны загружаться «с нетерпением» в том же запросе, что и родительский, с помощью JOIN или LEFT OUTER JOIN. Является ли объединение «внешним» или нет, определяется параметром relationship.innerjoin. * subquery - элементы должны загружаться «с нетерпением», по мере загрузки родительских элементов, с использованием одного дополнительного SQL-запроса, который выдает JOIN на подзапрос исходного запроса, для каждой запрашиваемой коллекции. * selectin - элементы должны загружаться «с нетерпением» по мере загрузки родительских объектов, используя один или несколько дополнительных SQL-операторов, которые выполняют JOIN к непосредственному родительскому объекту, указывая идентификаторы первичных ключей с помощью предложения IN. * noload - загрузка не должна происходить ни в какое время. Связанная коллекция будет оставаться пустой. Стратегия noload не рекомендуется для общего использования. Для общего использования подхода «никогда не загружать» смотрите Писать только отношения * raise - ленивая загрузка запрещена; обращение к атрибуту, если его значение еще не было загружено через eager loading, вызовет ошибку InvalidRequestError. Эта стратегия может быть использована, когда объекты после загрузки должны быть отсоединены от присоединенных к ним Session. * raise_on_sql - ленивая загрузка, выдающая SQL, запрещена; обращение к атрибуту, если его значение еще не было загружено с помощью ускоренной загрузки, вызовет ошибку InvalidRequestError, если ленивая загрузка должна выдавать SQL. Если ленивая загрузка может извлечь связанное значение из карты идентификаторов или определить, что оно должно быть None, то значение загружается. Эта стратегия может быть использована, когда объекты будут оставаться связанными с присоединенным Session, однако дополнительные операторы SELECT должны быть заблокированы. * write_only - в атрибуте будет настроена специальная «виртуальная коллекция», которая может получать команды WriteOnlyCollection.add() и WriteOnlyCollection.remove() для добавления или удаления отдельных объектов, но ни в коем случае не будет загружать или итерировать полный набор объектов из базы данных напрямую. Вместо этого предусмотрены методы WriteOnlyCollection.select(), WriteOnlyCollection.insert(), WriteOnlyCollection.update() и WriteOnlyCollection.delete(), генерирующие SQL-конструкции, которые можно использовать для массовой загрузки и модификации строк. Используются для больших коллекций, которые нецелесообразно загружать в память сразу. Стиль загрузчика write_only задается автоматически, если в декларативном отображении слева указана аннотация WriteOnlyMapped. Примеры см. в разделе Писать только отношения. … versionadded:: 2.0 .. seealso:: Писать только отношения - в Руководство по составлению запросов в ORM * dynamic - атрибут будет возвращать предварительно сконфигурированный Query объект dynamic для DynamicMapped всех Динамические загрузчики отношений операций Писать только отношения чтения, Динамические загрузчики отношений на который Руководство по составлению запросов в ORM могут Писать только отношения быть Техники загрузки отношений наложены Руководство по составлению запросов в ORM дальнейшие операции фильтрации

• load_on_pending=False – Указывает поведение загрузки для переходных или ожидающих родительских объектов. При значении True ленивый загрузчик выдает запрос на родительский объект, который не является постоянным, т.е. он никогда не подвергался промывке. Это может иметь место для отложенного объекта, когда автопромывка отключена, или для переходного объекта, который был «прикреплен» к Session, но не является частью его коллекции отложенных объектов. Флаг relationship.load_on_pending не улучшает поведение при обычном использовании ORM - ссылки на объекты должны строиться на уровне объектов, а не на уровне внешних ключей, чтобы они присутствовали обычным образом до того, как произойдет flush. Этот флаг не предназначен для общего использования. … seealso:: Session.enable_relationship_loading() - этот метод устанавливает поведение «загрузка при ожидании» для всего объекта, а также позволяет загружать объекты, которые остаются переходными или отсоединенными.

• order_by – Указывает порядок, который должен применяться при загрузке этих элементов. Ожидается, что relationship.order_by будет ссылаться на один из объектов Column, с которым сопоставлен целевой класс, или на сам атрибут, связанный с целевым классом, который ссылается на колонку. relationship.order_by также может быть передан в виде вызываемой функции, которая оценивается при инициализации маппера, и может быть передан в виде Python-выражаемой строки при использовании Declarative. … warning:: Если аргумент передается как Python-evaluable string, то он интерпретируется с помощью функции Python eval(). НЕ ПЕРЕДАВАЙТЕ В ЭТУ СТРОКУ НЕДОВЕРЕННЫЕ ДАННЫЕ. Подробнее о декларативной оценке аргументов Оценка аргументов в пользу отношений смотрите раздел relationship().

• passive_deletes=False – Указывает на поведение загрузки при операциях удаления. Значение True указывает на то, что незагруженные дочерние элементы не должны загружаться во время операции удаления родительского элемента. Обычно при удалении родительского элемента все дочерние элементы загружаются, чтобы их можно было либо пометить как удаленные, либо установить их внешний ключ к родительскому элементу в NULL. Установка этого флага как True обычно означает наличие правила ON DELETE <CASCADE|SET NULL>, которое будет обрабатывать обновление/удаление дочерних строк на стороне базы данных. Кроме того, установка флага в строковое значение „all“ отключает «обнуление» дочерних внешних ключей, когда родительский объект удален и не включен каскад удалений или удалений-орфанов. Это обычно используется в тех случаях, когда на стороне базы данных реализован сценарий срабатывания или предупреждения об ошибке. Обратите внимание, что атрибуты внешних ключей дочерних объектов в сеансе не будут изменены после удаления, так что это очень специфическая настройка. Кроме того, «обнуление» все равно произойдет, если дочерний объект будет деассоциирован с родительским. … см. также:: Использование каскада внешних ключей ON DELETE с отношениями ORM - Вводная документация и примеры.

• passive_updates=True – Указывает на поведение персистентности при изменении значения первичного ключа, на который ссылается столбец, и указывает на то, что столбцы внешнего ключа, на которые ссылается ключ, также должны изменить свое значение. При значении True предполагается, что для внешнего ключа в базе данных настроено значение ON UPDATE CASCADE, и база данных будет обрабатывать распространение UPDATE из исходного столбца в зависимые строки. Если False, то конструкция SQLAlchemy relationship() будет пытаться выдать собственные операторы UPDATE для модификации связанных целей. Однако следует иметь в виду, что SQLAlchemy не может испускать UPDATE более чем для одного уровня каскада. Кроме того, установка этого флага в значение False несовместима с тем случаем, когда база данных действительно обеспечивает ссылочную целостность, если только эти ограничения явно не «отложены», если целевой бэкенд поддерживает это. Настоятельно рекомендуется, чтобы приложение, использующее изменяемые первичные ключи, сохраняло значение passive_updates равным True, а для эффективной и полной обработки изменений использовало возможности ссылочной целостности самой базы данных. … см. также:: Изменяемые первичные ключи / Каскады обновлений - вводная документация и примеры. mapper.passive_updates - аналогичный флаг, действующий для отображений наследования объединенных таблиц.

• post_update – Это указывает на то, что связь должна быть обработана вторым оператором UPDATE после INSERT или перед DELETE. Этот флаг используется для сохранения двунаправленных зависимостей между двумя отдельными строками (т.е. каждая строка ссылается на другую), когда иначе было бы невозможно полностью выполнить INSERT или DELETE обеих строк, поскольку одна строка существует до другой. Этот флаг следует использовать в тех случаях, когда при определенной схеме отображения возникают две строки, зависящие друг от друга, например, таблица, имеющая отношение «один ко многим» к набору дочерних строк, а также столбец, ссылающийся на одну дочернюю строку в этом списке (т.е. обе таблицы содержат внешний ключ друг к другу). Если при операции flush возвращается ошибка о том, что обнаружена «циклическая зависимость», это сигнал к тому, что для «разрыва» цикла следует использовать relationship.post_update. … см. также:: Строки, указывающие сами на себя / Взаимозависимые строки - Вводная документация и примеры.

• primaryjoin – SQL-выражение, которое будет использоваться в качестве первичного соединения дочернего объекта с родительским объектом, или, в случае отношения «многие-ко-многим», в качестве соединения родительского объекта с таблицей ассоциации. По умолчанию это значение вычисляется на основе отношений внешних ключей родительской и дочерней таблиц (или таблицы ассоциации). relationship.primaryjoin может также передаваться в виде вызываемой функции, которая оценивается при инициализации картографа, а при использовании Declarative может передаваться в виде Python-выражаемой строки. … warning:: Если аргумент передается как Python-evaluable string, то он интерпретируется с помощью функции Python eval(). НЕ ПЕРЕДАВАЙТЕ В ЭТУ СТРОКУ НЕДОВЕРЕННЫЕ ДАННЫЕ. Подробнее о декларативной оценке аргументов Оценка аргументов в пользу отношений см. в разделе relationship(). … seealso:: Указание альтернативных условий присоединения

• remote_side – Используется для самореферентных отношений и указывает на столбец или список столбцов, которые образуют «удаленную сторону» отношения. relationship.remote_side может также передаваться как вызываемая функция, которая оценивается при инициализации картографа, и может передаваться как Python-выражаемая строка при использовании Declarative. … warning:: Если аргумент передается как Python-evaluable string, то он интерпретируется с помощью функции Python eval(). НЕ ПЕРЕДАВАЙТЕ В ЭТУ СТРОКУ НЕДОВЕРЕННЫЕ ДАННЫЕ. Подробнее о декларативной оценке аргументов Оценка аргументов в пользу отношений см. в разделе relationship(). … см. также:: Отношения в списке смежности - подробное объяснение того, как relationship.remote_side используется для настройки самореферентных отношений. remote() - функция аннотации, выполняющая ту же задачу, что и relationship.remote_side, обычно при использовании пользовательского условия relationship.primaryjoin.

• query_class – Подкласс Query, который будет использоваться внутри AppenderQuery, возвращаемого «динамическим» отношением, то есть отношением, в котором указано lazy="dynamic" или которое было построено иным образом с помощью функции dynamic_loader(). … см. также:: Динамические загрузчики отношений - Введение в «динамические» загрузчики отношений.

• secondaryjoin – SQL-выражение, которое будет использоваться в качестве соединения таблицы ассоциации с дочерним объектом. По умолчанию это значение вычисляется на основе отношений внешних ключей ассоциативной и дочерней таблиц. relationship.secondaryjoin также может быть передано в виде вызываемой функции, которая оценивается при инициализации картографа, и может быть передано в виде Python-выражаемой строки при использовании Declarative. … warning:: Если аргумент передается как Python-evaluable string, то он интерпретируется с помощью функции Python eval(). НЕ ПЕРЕДАВАЙТЕ В ЭТУ СТРОКУ НЕДОВЕРЕННЫЕ ДАННЫЕ. Подробнее о декларативной оценке аргументов Оценка аргументов в пользу отношений см. в разделе relationship(). … seealso:: Указание альтернативных условий присоединения

• single_parent – Если значение True, то устанавливается валидатор, который не позволяет объектам быть связанными более чем с одним родителем одновременно. Это используется для отношений «многие-к-одному» или «многие-ко-многим», которые должны рассматриваться либо как «один-к-одному», либо как «один-ко-многим». Ее использование необязательно, за исключением конструкций relationship(), которые являются отношениями «многие-к-одному» или «многие-ко-многим», а также указывают опцию delete-orphan cascade. Сама конструкция relationship() будет выдавать ошибку, указывающую на необходимость использования этой опции. … seealso:: Каскады - содержит подробную информацию о том, когда может быть уместен флаг relationship.single_parent.

• uselist – Булево значение, указывающее, должно ли данное свойство загружаться в виде списка или скаляра. В большинстве случаев это значение определяется автоматически relationship() во время конфигурирования картографа. При использовании явных аннотаций Mapped, relationship.uselist может быть выведено из того, содержит ли аннотация внутри Mapped класс коллекции или нет. В противном случае relationship.uselist может быть обусловлено типом и направлением отношения - один ко многим образует список, многие к одному - скаляр, многие ко многим - список. Если требуется скаляр там, где обычно присутствует список, например, при двунаправленном отношении «один к одному», используйте соответствующую аннотацию Mapped или установите флаг relationship.uselist в значение False. Флаг relationship.uselist также доступен в существующей конструкции relationship() как атрибут, доступный только для чтения, который может быть использован для определения того, работает ли данная конструкция relationship() с коллекциями или скалярными атрибутами:: >>> User.addresses.property.uselist True … seealso:: Один к одному - Знакомство с шаблоном отношений «один к одному», который обычно используется при альтернативной настройке relationship.uselist.

• viewonly=False – При установке значения True отношение используется только для загрузки объектов, но не для каких-либо операций персистентности. Отношение relationship(), в котором указан флаг relationship.viewonly, может работать с более широким спектром SQL-операций в рамках условия relationship.primaryjoin, включая операции, предусматривающие использование различных операторов сравнения, а также SQL-функций, таких как cast(). Флаг relationship.viewonly также имеет общее назначение при определении любого вида relationship(), не представляющего полный набор связанных объектов, для предотвращения модификации коллекции в результате операций персистентности. При использовании флага relationship.viewonly в сочетании с обратными ссылками исходное отношение для конкретного изменения состояния не будет вызывать изменения состояния в рамках отношения viewonly. Такое поведение подразумевается, если флаг relationship.sync_backref установлен в False. … versionchanged:: 1.3.17 - флаг relationship.sync_backref устанавливается в False при использовании viewonly в сочетании с обратными ссылками. … seealso:: relationship.sync_backref

• sync_backref – Булево значение, которое включает события, используемые для синхронизации атрибутов in-Python, когда это отношение является целью либо relationship.backref, либо relationship.back_populates. По умолчанию имеет значение None, что указывает на необходимость автоматического выбора значения на основе значения флага relationship.viewonly. Если оставить значение по умолчанию, изменения в состоянии будут обратно заполняться только в том случае, если ни одна из сторон отношения не является viewonly. … versionadded:: 1.3.17 .. versionchanged:: 1.4 - Отношение, в котором указано relationship.viewonly, автоматически подразумевает, что relationship.sync_backref является False. … seealso:: relationship.viewonly

• omit_join – Позволяет вручную управлять автоматической оптимизацией соединения «selectin». Установите значение False, чтобы отключить функцию «omit join», добавленную в SQLAlchemy 1.3; или оставьте значение None, чтобы оставить автоматическую оптимизацию на месте. … note:: Этот флаг может быть установлен только в значение False. Устанавливать его в значение True не обязательно, так как оптимизация «omit_join» определяется автоматически; если она не определяется, то оптимизация не поддерживается. … versionchanged:: 1.3.11 установка omit_join в True теперь будет выдавать предупреждение, так как этот флаг не предполагалось использовать. … versionadded:: 1.3

• init – Специфично для Декларативное отображение классов данных, указывает, должен ли отображаемый атрибут быть частью метода __init__(), генерируемого процессом класса данных.

• repr – Специфично для Декларативное отображение классов данных, указывает, должен ли отображаемый атрибут быть частью метода __repr__(), генерируемого процессом класса данных.

• default_factory – Специфично для Декларативное отображение классов данных, задает функцию генерации значения по умолчанию, которая будет выполняться в рамках метода __init__(), генерируемого процессом dataclass.

• compare – Специфично для Декларативное отображение классов данных, указывает, должно ли это поле включаться в операции сравнения при генерации методов __eq__() и __ne__() для сопоставленного класса. … versionadded:: 2.0.0b4

• kw_only – Специфично для Декларативное отображение классов данных, указывает, должно ли это поле быть помечено как предназначенное только для ключевого слова при генерации __init__().

function sqlalchemy.orm.backref(name: str, **kwargs: Any) → ORMBackrefArgument¶

При использовании параметра relationship.backref задает конкретные параметры, которые будут использоваться при генерации нового relationship().

Например:

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

Параметр relationship.backref обычно считается устаревшим; для современных приложений предпочтительнее использовать явные конструкции relationship(), связанные между собой с помощью параметра relationship.back_populates.

См.также

Использование унаследованного параметра отношения „backref“ - фон на обратных ссылках

function sqlalchemy.orm.dynamic_loader(argument: Optional[_RelationshipArgumentType[Any]] = None, **kw: Any) → RelationshipProperty[Any]¶

Постройте динамически загружаемое свойство mapper.

По сути, это то же самое, что использовать аргумент lazy='dynamic' с аргументом relationship():

dynamic_loader(SomeClass)

# is the same as

relationship(SomeClass, lazy="dynamic")

Более подробно о динамической загрузке см. раздел Динамические загрузчики отношений.

function sqlalchemy.orm.foreign(expr: _CEA) → _CEA¶

Аннотируйте часть выражения primaryjoin аннотацией „foreign“.

Описание использования см. в разделе Создание пользовательских иностранных условий.

См.также

Создание пользовательских иностранных условий

remote()

function sqlalchemy.orm.remote(expr: _CEA) → _CEA¶

Аннотируйте часть выражения primaryjoin аннотацией „remote“.

Описание использования см. в разделе Создание пользовательских иностранных условий.

См.также

Создание пользовательских иностранных условий

foreign()