Comments 12
Не надо доверять создание таблиц Hibernate. Эти скрипты нужно писать руками, лучше всего, если их будет писать человек, хорошо знакомый с используемой СУБД.
Пока что сталкивался с проблемами при использовании not null в колонках, ну и логика БД пожалуй не влезет в автогенерацию.
Но уж простые то операции, типа создать\обновить таблицы доверить можно…
рассматриваю подобные инструменты именно с целью использования автогенерации.
Для того, чтобы Hibernate создала базу именно такой, как надо, нужно очень хорошо владеть Hibernate и очень хорошо понимать конкретную СУБД.
Например, вы знаете какого типа Hibernate создаст колонку для поля типа UUID? Допустим, в случае с Oracle? И, возможно, вам нужен не вариант c varchar(36). Что делать, если нужно поддерживать 2 СУБД (это редкость, конечно, но тем не менее).
Какого типа будут созданы индексы? Можно ли этим как-то управлять? Допустим, вы это всё знаете, но вот человек, который хорошо понимает в Oracle с высокой вероятностью не очень хорошо понимает в Hibernate. Поэтому ему придётся объяснять вам, вам придётся всё это переводить в код, а дальше проверять, правильно ли создалась таблица. Гораздо удобнее просто написать SQL.
Так я о том и говорю, что автоматика просто не поймёт, что вам нужно, это придётся писать вручную, только не с помощью SQL, а с помощью фич Hibernate. А что случится, если кто-нибудь поменяте диалект? Могут поменяться правила генерации DDL. И вы будете уверены, что всё работает одним образом, а оно уже работает по другому. И всего этого можно избежать, если писать SQL руками.
Мне не доводилось эксплуатировать описанную схему в промышленных проектах, но было бы интересно попробовать.
На одном из проектов активно использовал инструменты от RedGate для построения SQL-скриптов с разницей. Почти всегда они получались именно такими как надо, но RedGate — инструмент совсем другого уровня.
Кроме того, бывали случаи, когда у существующего дробного поля уменьшаяем размерность. Если есть данные, то база ругнется о потенциальной потере информации.
В общем-то эти случаи не относятся напрямую к миграциям, а скорее в принципе к подходу накатывания этих изменений. Поэтому генерится у меня что-то, или пишется вручную — проверять потребуется в любом случае. Автоматика должна уменьшить человеческий фактор.
Да вот я тут целый комментарий написал.
name: id type: int
В результате при второй миграции падаем с Referencing column 'user_id' and referenced column 'id' in foreign key constraint 'FK2o0jvgh89lemvvo17cbqvdxaa' are incompatible. [Failed SQL:
ALTER TABLE users_roles ADD CONSTRAINT FK2o0jvgh89lemvvo17cbqvdxaa FOREIGN KEY (user_id) REFERENCES users (id)]
Использование Liquibase для управления структурой БД в Spring Boot приложении. Часть 2