Pull to refresh

Comments 12

Не надо доверять создание таблиц Hibernate. Эти скрипты нужно писать руками, лучше всего, если их будет писать человек, хорошо знакомый с используемой СУБД.

процитирую сюда из коммента к предыдущей статье:


описание миграции руками + validate у Hibernate, что сущность соответствует схеме в минимальном виде
рассматриваю подобные инструменты именно с целью использования автогенерации. Расскажите, какие конкретно ошибки всплывали с автогенерацией?
Пока что сталкивался с проблемами при использовании not null в колонках, ну и логика БД пожалуй не влезет в автогенерацию.
Но уж простые то операции, типа создать\обновить таблицы доверить можно…
рассматриваю подобные инструменты именно с целью использования автогенерации.

Для того, чтобы Hibernate создала базу именно такой, как надо, нужно очень хорошо владеть Hibernate и очень хорошо понимать конкретную СУБД.


Например, вы знаете какого типа Hibernate создаст колонку для поля типа UUID? Допустим, в случае с Oracle? И, возможно, вам нужен не вариант c varchar(36). Что делать, если нужно поддерживать 2 СУБД (это редкость, конечно, но тем не менее).


Какого типа будут созданы индексы? Можно ли этим как-то управлять? Допустим, вы это всё знаете, но вот человек, который хорошо понимает в Oracle с высокой вероятностью не очень хорошо понимает в Hibernate. Поэтому ему придётся объяснять вам, вам придётся всё это переводить в код, а дальше проверять, правильно ли создалась таблица. Гораздо удобнее просто написать SQL.

написать sql и короче и понятнее, но автоматика не пропустит изменений, которые может пропустить человек. Поэтому проверка — безусловно нужна, а вот написание однотипных альтеров — сомневаюсь. От ручных действий нужно уходить.

Так я о том и говорю, что автоматика просто не поймёт, что вам нужно, это придётся писать вручную, только не с помощью SQL, а с помощью фич Hibernate. А что случится, если кто-нибудь поменяте диалект? Могут поменяться правила генерации DDL. И вы будете уверены, что всё работает одним образом, а оно уже работает по другому. И всего этого можно избежать, если писать SQL руками.

А какая именно проблема с not null?

Мне не доводилось эксплуатировать описанную схему в промышленных проектах, но было бы интересно попробовать.

На одном из проектов активно использовал инструменты от RedGate для построения SQL-скриптов с разницей. Почти всегда они получались именно такими как надо, но RedGate — инструмент совсем другого уровня.
Да в общем-то не сложная. По ходу проекта добавляем новое поле в ранее созданную таблицу. По замыслу может подразумеваться, что поле всегда будет чем-то заполнено, поэтому обозначаем его как not null. Если локально данных в этой таблице нет, то миграция пройдет корректно. А вот на проде будет беда.
Кроме того, бывали случаи, когда у существующего дробного поля уменьшаяем размерность. Если есть данные, то база ругнется о потенциальной потере информации.
В общем-то эти случаи не относятся напрямую к миграциям, а скорее в принципе к подходу накатывания этих изменений. Поэтому генерится у меня что-то, или пишется вручную — проверять потребуется в любом случае. Автоматика должна уменьшить человеческий фактор.
А можете пример какой-то конкретной проблемной ситуации привести?
У вас в первом уроке при создании таблицы users в changeset
   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)]
Огромное спасибо, что проверили! Исправил тип поля id на BIGINT в первой части статьи.
Sign up to leave a comment.

Articles