Как предотвратить автоинкрементные конфликты между ветками?

Question

Допустим, у меня есть следующая схема и данные для ветви master:

CREATE TABLE `account_roles` (
  `account_role_id` tinyint(1) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(16) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `position` tinyint(1) unsigned NOT NULL,
  PRIMARY KEY (`account_role_id`),
  UNIQUE KEY `name` (`name`),
  KEY `position` (`position`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC;

INSERT INTO `account_roles` (`account_role_id`, `name`, `position`)
VALUES
    (1, 'Administrator', 1),
    (2, 'User', 2);

В нашем коде мы затем проверяем учетную запись account_role_id, чтобы определить их роль.

Теперь предположим, что мы создали две ветви master для двух новых функциональных возможностей, каждая из которых требует новой роли учетной записи. Каждая ветвь будет вставлять новую запись в таблицу account_roles следующим образом:

moderators ветвь:

INSERT INTO `account_roles` (`account_role_id`, `name`, `position`)
    VALUES (NULL, 'Moderator', '3');

sponsors ветвь:

INSERT INTO `account_roles` (`account_role_id`, `name`, `position`)
    VALUES (NULL, 'Sponsor', '3');

Ветвь moderators теперь имеет роль Модератора с account_role_id, равным 3, а ветвь sponsors теперь имеет роль Спонсора с account_role_id, равным 3, каждая проверяет наличие account_role_id, равным 3, при проверке, чтобы убедиться, что Аккаунт является Модератором / Спонсором. Очевидно, что это приведет к конфликту, когда они объединятся.

Каковы решения для решения этой проблемы? Я могу подумать о двух:

1. Объединить, а затем обновить код для проверки правильности account_role_id после выполнения запросов на миграцию базы данных.
2. Добавить уникальный * Столбец 1033 * (основанный на имени и который, мы надеемся, никогда не конфликтует), который мы запрашиваем для получения правильного account_role_id.

Answer 1

Вот что касается активных SQL схем и другого кода СУБД: они ничего не знают о ветвях контроля версий.

Итак, если у вас есть активная база данных, вы не можете развернуть новую версию, развернув измененный оператор CREATE TABLE: он заново создает новую пустую таблицу.

Чтобы изменить определение например, для добавления существующей таблицы необходимо развернуть изменение с помощью оператора ALTER TABLE. В этом случае существующие строки сохраняют свои автоматически увеличивающиеся значения столбцов id, а любые новые строки получают новые значения.

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

Мудрые разработчики пишут код SQL для обновления своих схем, а затем проверяют этот код на частных, разрабатываемых и промежуточных экземплярах базы данных. Затем сценарий запускается один раз в производственной базе данных во время развертывания в производство.