Отражение объектов базы данных¶

Переопределение отраженных столбцов¶

При отражении таблиц отдельные столбцы могут быть переопределены явными значениями; это удобно для указания пользовательских типов данных, ограничений, таких как первичные ключи, которые не могут быть настроены в базе данных, и т.д.:

>>> mytable = Table(
...     "mytable",
...     metadata_obj,
...     Column(
...         "id", Integer, primary_key=True
...     ),  # override reflected 'id' to have primary key
...     Column("mydata", Unicode(50)),  # override reflected 'mydata' to be Unicode
...     # additional Column objects which require no change are reflected normally
...     autoload_with=some_engine,
... )

Отражающие взгляды¶

Система отражения может также отражать представления. Базовое использование такое же, как и для таблицы:

my_view = Table("some_view", metadata, autoload_with=engine)

Выше, my_view представляет собой объект Table с объектами Column, представляющими имена и типы каждого столбца в представлении «some_view».

Обычно при отражении представления желательно иметь как минимум ограничение первичного ключа, а то и внешних ключей. Отражение представления не экстраполирует эти ограничения.

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

my_view = Table(
    "some_view",
    metadata,
    Column("view_id", Integer, primary_key=True),
    Column("related_thing", Integer, ForeignKey("othertable.thing_id")),
    autoload_with=engine,
)

Отражение всех столов одновременно¶

Объект MetaData также может получить листинг таблиц и отразить полный набор. Это достигается с помощью метода reflect(). После его вызова все расположенные таблицы присутствуют в словаре таблиц объекта MetaData:

metadata_obj = MetaData()
metadata_obj.reflect(bind=someengine)
users_table = metadata_obj.tables["users"]
addresses_table = metadata_obj.tables["addresses"]

metadata.reflect() также предоставляет удобный способ очистки или удаления всех строк в базе данных:

metadata_obj = MetaData()
metadata_obj.reflect(bind=someengine)
for table in reversed(metadata_obj.sorted_tables):
    someengine.execute(table.delete())

Отражение таблиц из других схем¶

Раздел Указание имени схемы вводит понятие схем таблиц, которые представляют собой пространства имен в базе данных, содержащие таблицы и другие объекты, и которые могут быть заданы в явном виде. Схема» для объекта Table, а также для других объектов, таких как представления, индексы и последовательности, может быть задана с помощью параметра Table.schema, а также в качестве схемы по умолчанию для объекта MetaData с помощью параметра MetaData.schema.

Использование этого параметра схемы напрямую влияет на то, куда будет смотреть функция отражения таблиц, когда ее попросят отразить объекты. Например, если объект MetaData сконфигурирован с именем схемы по умолчанию «project» через параметр MetaData.schema:

>>> metadata_obj = MetaData(schema="project")

Затем MetaData.reflect() будет использовать эту настроенную .schema для отражения:

>>> # uses `schema` configured in metadata_obj
>>> metadata_obj.reflect(someengine)

Конечным результатом будет то, что объекты Table из схемы «project» будут отражены, и они будут заполнены как schema-qualified с этим именем:

>>> metadata_obj.tables["project.messages"]
Table('messages', MetaData(), Column('message_id', INTEGER(), table=<messages>), schema='project')

Аналогично, отдельный объект Table, включающий параметр Table.schema, также будет отражен от схемы этой базы данных, переопределяя любую схему по умолчанию, которая могла быть настроена для принадлежащей коллекции MetaData:

>>> messages = Table("messages", metadata_obj, schema="project", autoload_with=someengine)
>>> messages
Table('messages', MetaData(), Column('message_id', INTEGER(), table=<messages>), schema='project')

Наконец, сам метод MetaData.reflect() также позволяет передать параметр MetaData.reflect.schema, поэтому мы могли бы также загрузить таблицы из схемы «проекта» для сконфигурированного по умолчанию объекта MetaData:

>>> metadata_obj = MetaData()
>>> metadata_obj.reflect(someengine, schema="project")

Мы можем вызывать MetaData.reflect() любое количество раз с разными аргументами MetaData.schema (или вообще без них), чтобы продолжить заполнение объекта MetaData новыми объектами:

>>> # add tables from the "customer" schema
>>> metadata_obj.reflect(someengine, schema="customer")
>>> # add tables from the default schema
>>> metadata_obj.reflect(someengine)

-- schema qualified
SELECT message_id FROM project.messages

-- non-schema qualified
SELECT message_id FROM messages

>>> # reflect in non-schema qualified fashion
>>> messages_table_1 = Table("messages", metadata_obj, autoload_with=someengine)
>>> # reflect in schema qualified fashion
>>> messages_table_2 = Table(
...     "messages", metadata_obj, schema="project", autoload_with=someengine
... )
>>> # two different objects
>>> messages_table_1 is messages_table_2
False
>>> # stored in two different ways
>>> metadata.tables["messages"] is messages_table_1
True
>>> metadata.tables["project.messages"] is messages_table_2
True

>>> # reflect "messages" in a schema qualified fashion
>>> messages_table_1 = Table(
...     "messages", metadata_obj, schema="project", autoload_with=someengine
... )

>>> messages_table_1.c.project_id
Column('project_id', INTEGER(), ForeignKey('project.projects.project_id'), table=<messages>)

>>> # reflect "projects" in a non-schema qualified fashion
>>> projects_table_1 = Table("projects", metadata_obj, autoload_with=someengine)

>>> # messages does not refer to projects_table_1 above
>>> messages_table_1.c.project_id.references(projects_table_1.c.project_id)
False

>>> it refers to this one
>>> projects_table_2 = metadata_obj.tables["project.projects"]
>>> messages_table_1.c.project_id.references(projects_table_2.c.project_id)
True

>>> they're different, as one non-schema qualified and the other one is
>>> projects_table_1 is projects_table_2
False

Мелкозернистое отражение с инспектором¶

Также доступен низкоуровневый интерфейс, обеспечивающий независимую от бэкенда систему загрузки списков описаний схем, таблиц, столбцов и ограничений из данной базы данных. Он известен как «Инспектор»:

from sqlalchemy import create_engine
from sqlalchemy import inspect

engine = create_engine("...")
insp = inspect(engine)
print(insp.get_table_names())

Отражение с помощью типов, не зависящих от базы данных¶

При отражении столбцов таблицы с помощью параметра Table.autoload_with в Table или метода Inspector.get_columns() в Inspector, типы данных будут как можно более специфичными для целевой базы данных. Это означает, что если тип данных «integer» отражается от базы данных MySQL, то этот тип будет представлен классом sqlalchemy.dialects.mysql.INTEGER, который включает специфические для MySQL атрибуты, такие как «display_width». Или на PostgreSQL может быть возвращен специфический для PostgreSQL тип данных, такой как sqlalchemy.dialects.postgresql.INTERVAL или sqlalchemy.dialects.postgresql.ENUM.

Для рефлексии существует случай использования, когда данный Table должен быть перенесен в базу данных другого производителя. Для этого случая существует техника, с помощью которой эти специфические для поставщика типы данных могут быть преобразованы «на лету» в экземпляры бэкенд-агностических типов данных SQLAlchemy, например, такие типы, как Integer, Interval и Enum. Это может быть достигнуто путем перехвата отражения столбца с помощью события DDLEvents.column_reflect() в сочетании с методом TypeEngine.as_generic().

Дана таблица в MySQL (выбрана потому, что MySQL имеет много специфических для производителя типов данных и опций):

CREATE TABLE IF NOT EXISTS my_table (
    id INTEGER PRIMARY KEY AUTO_INCREMENT,
    data1 VARCHAR(50) CHARACTER SET latin1,
    data2 MEDIUMINT(4),
    data3 TINYINT(2)
)

Приведенная выше таблица включает целочисленные типы MEDIUMINT и TINYINT, предназначенные только для MySQL, а также VARCHAR, который включает опцию CHARACTER SET, предназначенную только для MySQL. Если мы отразим эту таблицу нормально, то получится объект Table, который будет содержать эти специфические для MySQL типы данных и опции:

>>> from sqlalchemy import MetaData, Table, create_engine
>>> mysql_engine = create_engine("mysql://scott:tiger@localhost/test")
>>> metadata_obj = MetaData()
>>> my_mysql_table = Table("my_table", metadata_obj, autoload_with=mysql_engine)

Приведенный выше пример отражает схему таблицы в новом объекте Table. Затем, для демонстрации, мы можем вывести специфичный для MySQL оператор «CREATE TABLE», используя конструкцию CreateTable:

>>> from sqlalchemy.schema import CreateTable
>>> print(CreateTable(my_mysql_table).compile(mysql_engine))
CREATE TABLE my_table (
id INTEGER(11) NOT NULL AUTO_INCREMENT,
data1 VARCHAR(50) CHARACTER SET latin1,
data2 MEDIUMINT(4),
data3 TINYINT(2),
PRIMARY KEY (id)
)ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

Выше, специфические для MySQL типы данных и опции были сохранены. Если нам нужен Table, который мы могли бы перенести в другой поставщик баз данных, заменив специальные типы данных sqlalchemy.dialects.mysql.MEDIUMINT и sqlalchemy.dialects.mysql.TINYINT на Integer, мы можем вместо этого «обобщить» типы данных в этой таблице или изменить их любым другим способом, создав обработчик с помощью события DDLEvents.column_reflect(). Пользовательский обработчик будет использовать метод TypeEngine.as_generic() для преобразования вышеуказанных объектов типов, специфичных для MySQL, в общие, путем замены записи "type" в словаре столбцов, который передается обработчику события. Формат этого словаря описан в Inspector.get_columns():

>>> from sqlalchemy import event
>>> metadata_obj = MetaData()

>>> @event.listens_for(metadata_obj, "column_reflect")
>>> def genericize_datatypes(inspector, tablename, column_dict):
...     column_dict["type"] = column_dict["type"].as_generic()

>>> my_generic_table = Table("my_table", metadata_obj, autoload_with=mysql_engine)

Теперь мы получаем новый Table, который является общим и использует Integer для этих типов данных. Теперь мы можем выдать оператор «CREATE TABLE», например, для базы данных PostgreSQL:

>>> pg_engine = create_engine("postgresql://scott:tiger@localhost/test", echo=True)
>>> my_generic_table.create(pg_engine)
CREATE TABLE my_table (
    id SERIAL NOT NULL,
    data1 VARCHAR(50),
    data2 INTEGER,
    data3 INTEGER,
    PRIMARY KEY (id)
)

Отметим также, что SQLAlchemy обычно делает приличные предположения относительно других моделей поведения, например, что директива MySQL AUTO_INCREMENT представлена в PostgreSQL наиболее близко с помощью автоинкрементного типа данных SERIAL.

Ограничения рефлексии¶

Важно отметить, что процесс отражения воссоздает метаданные Table, используя только ту информацию, которая представлена в реляционной базе данных. Этот процесс по определению не может восстановить аспекты схемы, которые на самом деле не хранятся в базе данных. Состояние, которое недоступно при отражении, включает, но не ограничивается этим:

• Умолчания на стороне клиента, либо функции Python, либо выражения SQL, определенные с помощью ключевого слова default в Column (обратите внимание, что это отдельно от server_default, что конкретно доступно через отражение).

• Информация о столбцах, например, данные, которые могли быть помещены в словарь Column.info

• Значение настройки .quote для Column или Table

• Связь конкретного Sequence с конкретным Column

Реляционная база данных также во многих случаях сообщает метаданные таблицы в формате, отличном от того, который был указан в SQLAlchemy. Нельзя всегда полагаться на то, что объекты Table, возвращаемые в результате рефлексии, будут создавать идентичный DDL, как и исходные объекты Table, определяемые Python. К таким областям относятся серверные значения по умолчанию, последовательности, связанные с колонками, и различные идиосинкразии в отношении ограничений и типов данных. Умолчания на стороне сервера могут быть возвращены с помощью директив приведения (обычно PostgreSQL включает приведение ::<type>) или шаблонов цитирования, отличных от первоначально заданных.

Другая категория ограничений включает структуры схем, для которых отражение определено лишь частично или еще не определено. Недавние усовершенствования отражения позволяют отражать такие вещи, как представления, индексы и опции внешних ключей. На данный момент такие структуры, как ограничения CHECK, комментарии к таблицам и триггеры, не отражаются.