Версионирование схем баз данных — различия между версиями

Материал из YourcmcWiki
Перейти к: навигация, поиск
Строка 1: Строка 1:
Идея - создать возможность построения скриптов обновления или отката любой версии базы данных до любой другой. Можно описывать изменения в комментариях к коммитам в систему контроля версий. Но так как база данных - "это вам не readme.txt", то в каждом изменении нужно отдельно описывать как применение изменения, так и его откат, на рабочую базу данных с загруженными данными. Либо можно генерировать простые изменения автоматически, по схеме БД - например, добавления и удаления колонок.
+
Идея — создать возможность построения скриптов обновления или отката любой версии базы данных до любой другой. Можно описывать изменения в комментариях к коммитам в систему контроля версий. Но так как база данных — «это вам не readme.txt», то в каждом изменении нужно отдельно описывать как применение изменения, так и его откат, на рабочую базу данных с загруженными данными. Либо можно генерировать простые изменения автоматически, по схеме БД — например, добавления и удаления колонок.
  
Итак, если изменения описываются в комментариях к изменениям, то на svn commit можно поставить хук, проверяющий наличие описаний и не дающий закоммитить без них, например, файлы с некоторым расширением - например, *.vsql ("Versioned SQL").
+
Итак, если изменения описываются в комментариях к изменениям, то на svn commit можно поставить хук, проверяющий наличие описаний и не дающий закоммитить без них, например, файлы с некоторым расширением — например, *.vsql («Versioned SQL»).
  
Далее - нужно создать утилиту, которая по SVN log'у сможет строить скрипты для обновления или отката любой версии БД до любой другой по комментариям и описаниям БД, фактически представляющие собой списки файлов SQL, в них включаемых. Т.е. в свою БД можно набирать таблицы для разных фич, к примеру.
+
Далее — нужно создать утилиту, которая по SVN log’у сможет строить скрипты для обновления или отката любой версии БД до любой другой по комментариям и описаниям БД, фактически представляющие собой списки файлов SQL, в них включаемых. То есть в свою БД можно набирать таблицы для разных фич, к примеру.
  
 
Описания:
 
Описания:
Строка 15: Строка 15:
  
 
# Нужно как-то обрабатывать '''сложные пути по дереву ревизий'''. Например, две развившиеся ветки, в каждой есть свои скрипты обновления, соответственно нужно сначала откатить одну до момента пересечения, а потом накатить вторую до нужной ревизии;
 
# Нужно как-то обрабатывать '''сложные пути по дереву ревизий'''. Например, две развившиеся ветки, в каждой есть свои скрипты обновления, соответственно нужно сначала откатить одну до момента пересечения, а потом накатить вторую до нужной ревизии;
# И второй вопрос - как быть в случае, если какая-то функциональность в БД зависит от одновременного наличия ДВУХ "фич" ? Пример: маппер URI, поддерживающий колонку uri в каждой таблице объектов и отдельную таблицу uris, которая поддерживается триггерами по всем таким таблицам в актуальном состоянии, а также может быть пересобрана. Соответственно каждый триггер зависит от одновременного наличия маппера и собственно фичи, которая даёт соответствующую таблицу.
+
# И второй вопрос — как быть в случае, если какая-то функциональность в БД зависит от одновременного наличия ДВУХ «фич» ? Пример: маппер URI, поддерживающий колонку uri в каждой таблице объектов и отдельную таблицу uris, которая поддерживается триггерами по всем таким таблицам в актуальном состоянии, а также может быть пересобрана. Соответственно каждый триггер зависит от одновременного наличия маппера и собственно фичи, которая даёт соответствующую таблицу.
  
 
[[Категория:Разработка]]
 
[[Категория:Разработка]]

Версия 01:32, 31 августа 2009

Идея — создать возможность построения скриптов обновления или отката любой версии базы данных до любой другой. Можно описывать изменения в комментариях к коммитам в систему контроля версий. Но так как база данных — «это вам не readme.txt», то в каждом изменении нужно отдельно описывать как применение изменения, так и его откат, на рабочую базу данных с загруженными данными. Либо можно генерировать простые изменения автоматически, по схеме БД — например, добавления и удаления колонок.

Итак, если изменения описываются в комментариях к изменениям, то на svn commit можно поставить хук, проверяющий наличие описаний и не дающий закоммитить без них, например, файлы с некоторым расширением — например, *.vsql («Versioned SQL»).

Далее — нужно создать утилиту, которая по SVN log’у сможет строить скрипты для обновления или отката любой версии БД до любой другой по комментариям и описаниям БД, фактически представляющие собой списки файлов SQL, в них включаемых. То есть в свою БД можно набирать таблицы для разных фич, к примеру.

Описания:

  • SQL, встроенный в комментарий: APPLY|ROLLBACK INLINE ALTER TABLE t CHANGE f f INT DEFAULT NULL;
  • SQL из внешнего скрипта: APPLY|ROLLBACK SCRIPT version/changescript.sql;
  • Для дампов (полная перезапись, база очищается перед применением): APPLY|ROLLBACK OVERWRITE;
  • Автоматическая генерация операторов: AUTO SCHEMA;

Но здесь есть и вопросы.

  1. Нужно как-то обрабатывать сложные пути по дереву ревизий. Например, две развившиеся ветки, в каждой есть свои скрипты обновления, соответственно нужно сначала откатить одну до момента пересечения, а потом накатить вторую до нужной ревизии;
  2. И второй вопрос — как быть в случае, если какая-то функциональность в БД зависит от одновременного наличия ДВУХ «фич» ? Пример: маппер URI, поддерживающий колонку uri в каждой таблице объектов и отдельную таблицу uris, которая поддерживается триггерами по всем таким таблицам в актуальном состоянии, а также может быть пересобрана. Соответственно каждый триггер зависит от одновременного наличия маппера и собственно фичи, которая даёт соответствующую таблицу.