ru_java


ru.java

все о языке программирования java


Previous Entry Share Next Entry
java database versioning
vissarion wrote in ru_java
Господа,
вы же все, в основном, всё равно сидите на SQL,
с хибернейтом там или напрямую.
Раскройте секрет, как вы контролируете версии базы данных?
т.е есть версия #1 какого-нибудь класса, например User с полями String lastname, String firstname
соответственно, в базе есть такая же таблица типа
<pre>
CREATE TABLE Users (
user_id INT NOT NULL,
firstname VARCHAR,
lastname VARCHAR
)
</pre>
выкатили версию #2 класса User в котором добавили какой-нибудь String middlename
Очевидно что класс версии #2 на бд версии #1 работать не будет, нужно апгрейдить бд тоже.
Вопрос к залу: как сейчас модно решать проблему синхронизации версии бд  с версией приложения?
Очевидно, что можно сказать "это проблема дба, джавистов не колышет", но может быть есть что-то поинтереснее?
Гугл находит всякие варианты типа liquibase и flyaway, это именно то что все реально используют в продакшне ?

  • 1
Liquibase - вещь. Использовали в продакшне, проблем не было.

По моему опыту - небольшое число проектов использует именно их. Большое число проектов - использует самописные велосипеды.

лисапед наше всё.

Для простых проектов -
CREATE TABLE Config (
  name  VARCHAR(80) PRIMARY KEY,
  value VARCHAR(255)
);

INSERT INTO Config (name, value) VALUES ('version', '1.0');

И при старте сервера читаем версию, если есть upgrade скрипт - ставим лок, выполняем upgrade_1.0_2.0.sql, снимаем лок. Если нет апгрейда, опускаем сервер и отказываемся работать.
В принципе там немного кода.


Для сложных проектов - liquidbase.
В любом случае важно иметь сгенерированные апгрейд-скрипты. Например, если alter table только суперюзером и этот DBA не признает автоматизацию таких вещей. Тогда все превращается в ручной процесс.

И все это (включая flyway) не работает если компания следует, например, git flow и есть автоматизация сборки / деплоймента. Ибо бренчи...

Есть автоматизация. Отлично работает. Пофиг на бренчи.

у нас flyway, никаких особых требований к нему не предъявлялось, но то что надо (sql и java-скрипты) он делает

Использовали PL/SQL обертки для проверки необходимости апгрейда и самого апгрейда. Сейчас используем flyway как развитие предыдущего подхода.
Опыт положительный.

достаточно простая тулза MyBatis Migrations.

Завелосипедили.
В базе хранится номер версии, на каждую новую версию - свой небольшой update скрипт.
Сервер стартует, если видит что версия старая, накатывает апдейты.
Хотя проект большой, проблем не было, работает как часы.

Если нужна поддержка многих БД - лучше liquibase.
Если нужна поддержка только одной БД, подойдёт (и, возможно, будет удобнее) flyway.

1) условная таблица "Version" с одной колонкой и строкой.
Плюс инкрементальные скрипты

2) велосипед, анализирующий текущую структуру базу и сравнивающую её с объектной структурой "как надо". Получаем дифф из действий, которые накатываем.

Автоматически генеренный дифф поможет только в самых простейших случаях.

Была таблица address с полем varchar city
Решили в версии софта N+1, значение varchar city вынести в отдельную таблицу и заменить в таблице address поле varchar city на number cityid.

Софтина, которая сможет распознать конвертацию из varchar в foreign key, и написать миграционные скрипты, которые не похерят данные, потянет на нобелевскую премию.

Думаю, автоматически это нерешаемо.

Edited at 2015-11-08 09:51 pm (UTC)

а разве так вообще реально сделать? адреса пишут так, как рука ляжет. В конкретном примере видел переименование address -> old_address и добавление новой колонки с внешним ключом.

Я в одном среднем проекте наваял инсталятор который проверял версию БД и накатывал скрипт обновления структуры БД. Скрипт лежал в VCS и разработчики в процессе разработки очередного релиза туда вписывали чего им надо. Потом собирался инсталятор. Проект работал на DB2.

Т.е. велосипед :)

На локальных инстансах разработчиков - ORM'ом. Перед выкаткой на прод отдавали новую схему DBA ( в идеальном случае ). Либо, если уверены что ORM ничего не сломает ( добавление новой таблицы например ) - стопали морду, грузили с autocreate, проверяли, грузили с verify, включали морду.

В одном из opensource проектов - закостылил dbVersion и к каждой захардкоден SQL для апдейта.
Но это standalone который может проапгрейдится с 0.9 до 1.6 за раз.

С использованием миграций апдейт делится на две части: неломающий и ломающий. Например для переименования первый апдейт создает колонку и переносит данные, а второй апдейт (только после того как не останется старых версий) удаляет колонку

А так да flyway рулит

Edited at 2015-11-09 09:50 am (UTC)

  • 1
?

Log in