Манипулирование данными с помощью ORM¶

Вставка строк с помощью ORM¶

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

>>> squidward = User(name="squidward", fullname="Squidward Tentacles")
>>> krabs = User(name="ehkrabs", fullname="Eugene H. Krabs")

>>> squidward
User(id=None, name='squidward', fullname='Squidward Tentacles')

>>> session = Session(engine)

>>> session.add(squidward)
>>> session.add(krabs)

>>> session.new
IdentitySet([User(id=None, name='squidward', fullname='Squidward Tentacles'), User(id=None, name='ehkrabs', fullname='Eugene H. Krabs')])

>>> session.flush()
BEGIN (implicit)
INSERT INTO user_account (name, fullname) VALUES (?, ?)
[...] ('squidward', 'Squidward Tentacles')
INSERT INTO user_account (name, fullname) VALUES (?, ?)
[...] ('ehkrabs', 'Eugene H. Krabs')

>>> squidward.id
4
>>> krabs.id
5

>>> some_squidward = session.get(User, 4)
>>> some_squidward
User(id=4, name='squidward', fullname='Squidward Tentacles')

>>> some_squidward is squidward
True

>>> session.commit()
COMMIT

Обновление объектов ORM¶

В предыдущем разделе Обновление и удаление строк с помощью Core мы представили конструкцию Update, которая представляет собой оператор SQL UPDATE. При использовании ORM существует два способа применения этой конструкции. Основной способ заключается в том, что она выполняется автоматически как часть процесса unit of work, используемого Session, где оператор UPDATE выполняется на основе каждого первичного ключа, соответствующего отдельным объектам, в которых произошли изменения. Вторая форма UPDATE называется «UPDATE с поддержкой ORM» и позволяет нам использовать конструкцию Update с Session в явном виде; это описано в следующем разделе.

Предположим, мы загрузили объект User для имени пользователя sandy в транзакцию (также демонстрируя метод Select.filter_by(), а также метод Result.scalar_one()):

sql>>> sandy = session.execute(select(User).filter_by(name="sandy")).scalar_one()
BEGIN (implicit)
SELECT user_account.id, user_account.name, user_account.fullname
FROM user_account
WHERE user_account.name = ?
[...] ('sandy',)

Объект Python sandy, как уже упоминалось, действует как прокси для строки в базе данных, точнее, строки базы данных в терминах текущей транзакции, которая имеет первичный ключ 2:

>>> sandy
User(id=2, name='sandy', fullname='Sandy Cheeks')

Если мы изменяем атрибуты этого объекта, Session отслеживает это изменение:

>>> sandy.fullname = "Sandy Squirrel"

Объект появляется в коллекции под названием Session.dirty, указывая на то, что объект «грязный»:

>>> sandy in session.dirty
True

Когда Session в следующий раз выдает flush, будет выдан UPDATE, который обновит это значение в базе данных. Как упоминалось ранее, flush происходит автоматически до того, как мы выдадим какой-либо SELECT, используя поведение, известное как autoflush. Мы можем напрямую запросить столбец User.fullname из этой строки и получим обратно обновленное значение:

>>> sandy_fullname = session.execute(select(User.fullname).where(User.id == 2)).scalar_one()
UPDATE user_account SET fullname=? WHERE user_account.id = ?
[...] ('Sandy Squirrel', 2)
SELECT user_account.fullname
FROM user_account
WHERE user_account.id = ?
[...] (2,)
>>> print(sandy_fullname)
Sandy Squirrel

Выше мы видим, что мы запросили, чтобы Session выполнил один оператор select(). Однако выданный SQL показывает, что также было выдано UPDATE, что является процессом промывки, выталкивающим отложенные изменения. Объект sandy Python теперь больше не считается грязным:

>>> sandy in session.dirty
False

Однако обратите внимание, что мы все еще находимся в транзакции, и наши изменения не были перенесены в постоянное хранилище базы данных. Поскольку фамилия Сэнди на самом деле «Чикс», а не «Белка», мы исправим эту ошибку позже, когда откатим транзакцию. Но сначала мы сделаем еще несколько изменений данных.

>>> session.execute(
...     update(User)
...     .where(User.name == "sandy")
...     .values(fullname="Sandy Squirrel Extraordinaire")
... )
UPDATE user_account SET fullname=? WHERE user_account.name = ?
[...] ('Sandy Squirrel Extraordinaire', 'sandy')
<sqlalchemy.engine.cursor.CursorResult object ...>

>>> sandy.fullname
'Sandy Squirrel Extraordinaire'

Удаление объектов ORM¶

В завершение основных операций персистентности отдельный объект ORM может быть помечен для удаления с помощью метода Session.delete(). Давайте загрузим patrick из базы данных:

sql>>> patrick = session.get(User, 3)
SELECT user_account.id AS user_account_id, user_account.name AS user_account_name,
user_account.fullname AS user_account_fullname
FROM user_account
WHERE user_account.id = ?
[...] (3,)

Если мы помечаем patrick для удаления, как и в случае с другими операциями, то пока не произойдет flush, фактически ничего не произойдет:

>>> session.delete(patrick)

Текущее поведение ORM заключается в том, что patrick остается в Session до тех пор, пока не произойдет flush, который, как уже упоминалось, происходит, если мы выдаем запрос:

>>> session.execute(select(User).where(User.name == "patrick")).first()
SELECT address.id AS address_id, address.email_address AS address_email_address,
address.user_id AS address_user_id
FROM address
WHERE ? = address.user_id
[...] (3,)
DELETE FROM user_account WHERE user_account.id = ?
[...] (3,)
SELECT user_account.id, user_account.name, user_account.fullname
FROM user_account
WHERE user_account.name = ?
[...] ('patrick',)

Выше, SELECT, который мы попросили выдать, предшествовал DELETE, что указывало на предстоящее удаление для patrick. Также был выполнен запрос SELECT к таблице address, который был вызван тем, что ORM ищет в этой таблице строки, которые могут быть связаны с целевой строкой; это поведение является частью поведения, известного как cascade, и его можно настроить для более эффективной работы, позволив базе данных автоматически обрабатывать связанные строки в address; в разделе удалить об этом подробно рассказывается.

Кроме того, удаляемый экземпляр объекта patrick больше не считается постоянным внутри Session, как показано проверкой содержимого:

>>> patrick in session
False

Однако, как и в случае с UPDATE, которые мы сделали в объекте sandy, каждое изменение, которое мы сделали здесь, является локальным для текущей транзакции, которая не станет постоянной, если мы ее не зафиксируем. Поскольку откат транзакции на данный момент более интересен, мы сделаем это в следующем разделе.

>>> # refresh the target object for demonstration purposes
>>> # only, not needed for the DELETE
sql>>> squidward = session.get(User, 4)
SELECT user_account.id AS user_account_id, user_account.name AS user_account_name,
user_account.fullname AS user_account_fullname
FROM user_account
WHERE user_account.id = ?
[...] (4,)

>>> session.execute(delete(User).where(User.name == "squidward"))
DELETE FROM user_account WHERE user_account.name = ?
[...] ('squidward',)
<sqlalchemy.engine.cursor.CursorResult object at 0x...>

>>> squidward in session
False

Откат¶

У Session есть метод Session.rollback(), который, как и ожидалось, выдает ROLLBACK на текущем SQL-соединении. Однако он также влияет на объекты, которые в настоящее время связаны с Session, в нашем предыдущем примере объект Python sandy. Хотя мы изменили .fullname объекта sandy на чтение "Sandy Squirrel", мы хотим откатить это изменение. Вызов Session.rollback() не только откатит транзакцию, но и удалит все объекты, в настоящее время связанные с этим Session, что приведет к тому, что они обновятся при следующем обращении к ним с помощью процесса, известного как lazy loading:

>>> session.rollback()
ROLLBACK

Чтобы рассмотреть процесс «истечения» более внимательно, мы можем заметить, что у объекта Python sandy не осталось никакого состояния внутри его Python __dict__, за исключением специального объекта внутреннего состояния SQLAlchemy:

>>> sandy.__dict__
{'_sa_instance_state': <sqlalchemy.orm.state.InstanceState object at 0x...>}

Это состояние «expired»; повторное обращение к атрибуту приведет к автозапуску новой транзакции и обновлению sandy с текущей строкой базы данных:

>>> sandy.fullname
BEGIN (implicit)
SELECT user_account.id AS user_account_id, user_account.name AS user_account_name,
user_account.fullname AS user_account_fullname
FROM user_account
WHERE user_account.id = ?
[...] (2,)
'Sandy Cheeks'

Теперь мы можем заметить, что полная строка базы данных также была заполнена в __dict__ объекта sandy:

>>> sandy.__dict__  
{'_sa_instance_state': <sqlalchemy.orm.state.InstanceState object at 0x...>,
 'id': 2, 'name': 'sandy', 'fullname': 'Sandy Cheeks'}

Для удаленных объектов, когда мы ранее отметили, что patrick больше не находится в сессии, идентичность этого объекта также восстанавливается:

>>> patrick in session
True

и, конечно, данные базы данных также присутствуют:

sql>>> session.execute(select(User).where(User.name == "patrick")).scalar_one() is patrick
SELECT user_account.id, user_account.name, user_account.fullname
FROM user_account
WHERE user_account.name = ?
[...] ('patrick',)
True

Закрытие сеанса¶

В приведенных выше разделах мы использовали объект Session вне контекстного менеджера Python, то есть не использовали оператор with. Это нормально, однако, если мы будем действовать таким образом, лучше всего явно закрыть Session, когда мы закончим с ним:

>>> session.close()
ROLLBACK

Закрытие Session, что происходит, когда мы используем его и в менеджере контекста, приводит к следующим результатам:

• Это releases все ресурсы соединения в пул соединений, отменяя (например, откатывая) все транзакции, которые находились в процессе выполнения.

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

• Он удаляет все объекты из Session.

  Это означает, что все объекты Python, которые мы загрузили для этого Session, такие как sandy, patrick и squidward, теперь находятся в состоянии, известном как detached. В частности, отметим, что объекты, которые все еще находились в состоянии expired, например, из-за вызова Session.commit(), теперь нефункциональны, поскольку они не содержат состояния текущей строки и больше не связаны ни с какой транзакцией базы данных, в которой должны быть обновлены:

  >>> squidward.name
  Traceback (most recent call last):
    ...
  sqlalchemy.orm.exc.DetachedInstanceError: Instance <User at 0x...> is not bound to a Session; attribute refresh operation cannot proceed

  Отсоединенные объекты могут быть повторно ассоциированы с тем же или новым Session с помощью метода Session.add(), который восстановит их связь с конкретной строкой базы данных:

  >>> session.add(squidward)
  >>> squidward.name
  BEGIN (implicit)
  SELECT user_account.id AS user_account_id, user_account.name AS user_account_name, user_account.fullname AS user_account_fullname
  FROM user_account
  WHERE user_account.id = ?
  [...] (4,)
  'squidward'

  Совет

  По возможности старайтесь не использовать объекты в их отсоединенном состоянии. Когда Session закрывается, очистите также ссылки на все ранее присоединенные объекты. Для случаев, когда отсоединенные объекты необходимы, например, для немедленного отображения только что зафиксированных объектов в веб-приложении, где Session закрывается перед отрисовкой представления, установите флаг Session.expire_on_commit в значение False.