С документы :
Аргументом ForeignKey
чаще всего является строка вида <tablename>.<columnname>
или для таблицы в удаленной схеме или «владелец »формы <schemaname>.<tablename>.<columnname>
.Это также может быть фактический Column
объект ...
При определении ForeignKey
для Cars.id_model
вы передаете строковую форму имени класса ('Models'
), которое не являетсяпринятая форма.
Однако вы можете успешно определить свой внешний ключ, используя один из следующих параметров:
ForeignKey(Models.id_model)
При этом используется фактический объект Column
для указания внешнего ключа.Недостатком этого метода является то, что вам нужно иметь столбец в вашем пространстве имен, что добавляет дополнительную сложность необходимости импортировать модель в модуль, если она там не определена, а также может привести к тому, что вы будете заботиться о порядке создания экземпляров ваших моделей.,Вот почему более распространено использовать один из строковых параметров, например:
ForeignKey('models.id_model')
Обратите внимание, что в этом примере не указана строковая версия имени класса (не M *).1026 * odels.id_model) а точнее строковая версия имени таблицы.Строковая версия означает, что требуемые табличные объекты разрешаются только при необходимости и поэтому избегают сложностей работы с Column
самими объектами.
Еще один интересный пример, который работает в данном случае :
ForeignKey('models')
Если два столбца имеют одинаковые имена в обеих таблицах, SQLAlchemy, по-видимому, выводит столбец из таблицы.Если вы измените имя любого из определений столбцов id_model
в вашем примере, чтобы они назывались по-другому, это перестанет работать.Кроме того, я не нашел, чтобы это было хорошо задокументировано, и оно менее явное, поэтому я не уверен, действительно ли это стоит использовать, и я просто упомянул для полноты и потому, что мне это показалось интересным.Комментарий в исходном коде ForeignKey._column_tokens()
, по-видимому, был более явным, чем документы в отношении допустимого форматирования column
arg:
# A FK between column 'bar' and table 'foo' can be
# specified as 'foo', 'foo.bar', 'dbo.foo.bar',
# 'otherdb.dbo.foo.bar'. Once we have the column name and
# the table name, treat everything else as the schema
# name.