Быстрое и простое решение

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

Эта статья представляет собой лишь краткий обзор решения.

Что такое конфликт? Как мы с ними справляемся?

Конфликт — это когда любые две строки в таблице идентичны в подмножестве столбцов, которое я называю data_conflict_properties . Например, если у меня есть таблица с первичным ключом id:

Попытка написать id=1, name=yousef и surname=nami — полный конфликт. Однако я мог бы определить свойства конфликта только для id, то есть я не мог бы написать новую запись с id=1. Фактически, именно это и делает первичный ключ в базе данных. С помощью data_conflict_properties я предлагаю гибкий способ выбора свойств, которые вы хотите проверять на наличие конфликтов, без обязательного определения этих свойств как первичных ключей или ограничений уникальности.

Теперь, когда мы понимаем, что такое конфликты… как нам с ними справиться? Вот четыре варианта:

  • добавить: это означает, что независимо от того, есть или нет конфликт, вы добавляете новую строку (альтернативно, добавление может означать «пропустить проверку конфликта»)
  • игнорировать: это означает, что конфликтующие строки просто удаляются из процесса записи. Обычно это тот случай, когда вы хотите сохранить данные, которые были впервые записаны в базу данных.
  • replace: это означает, что конфликтующие строки мы заменяем новыми. Это больше похоже на операцию «обновления»
  • fail: это означает, что мы не выполним весь запрос, если есть один конфликт. Это для случая, когда вы не можете допустить, чтобы какие-либо данные были неверными.

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

Простая стратегия разрешения конфликтов

Раньше мой код записи в базу данных выглядел примерно так: