Как создавать правильно таблицы с помощью Hibernate?
Приветствую тебя уважаемый!
Прошу помощи. Хочу найти ответ на то как создавать таблицы в пустой базе данных(mysql) с помощью Hibernate возможно ли такое и насколько это целесообразно?
Есть ли какие то примеры либо ссылки. Очень благодарен буду тебе за помощь!
Возможно. Целесообразно, если модели и связи более-менее простые. Нужно просто задать проперти с именем "hbm2ddl.auto" значение "update".
Достигается путём добавления строчки в конфиг persistence.xml: <property name="hbm2ddl.auto" value="update"/>
Можно ещё и программно настроить, погугли как.
Спасибо за ответ. У меня этот вопрос возник из-за того, что по данному примеру (property name="hbm2ddl.auto" value="update") в Интернете постоянно натыкаюсь на статьи с названием автосоздание таблиц и в качестве схемы приводится уже созданная таблица (взятая за основу). Да и почему не value="create", а value="update", что бы при каждом обращении не переписывать ее без изменений?
И я правильно понял что для создания таблицы в базе, грубо говоря надо описать ее в виде сущности?
Спасибо!
Amurchikus:
Hibernate сам сможет из сущности сгенерировать ddl для таблиц. Имена столбцов возьмёт в виде строкового представления полей у которых есть публичные геттеры/сеттеры. Название таблицы - имя класса. Внешние ключи - имя связанной сущности + _id.
Но лучше всё самому описать аннотациями. Вот список частоиспользуемых, там уж сам погугли про их значения и параметры (например, вот хороший сайт с описанием):
Спасибо bromzh. Детальней изучил этот вопрос. И все получилось. Через параметр hbm2ddl.auto действительно hibernate проверяет сущности с таблицей БД и если схема отсутсвует то при налиичаи той или иной сущности она будет создана в базе. Очень удобно, даже не паришся - посмотрел какие у тебя объекты и дальше уже понимаешь что есть или что надо еще. )))
Amurchikus: Да. И если ты добавлял аннотации @Table @Column и ещё некоторые, Idea (если ты используешь её) даже может связать это с datasource и подсвечивать, есть ли такие поля в таблицах.
Но заранее хочу сказать, не стоит доверять полностью генерацию хибернейту. Например, он не знает как в постгресе правильно создавать автоинкрементальные (SERIAL PRIMARY KEY) поля (через аннотацию @GeneratedValue). Через аннотации это решается путём создания sequence (тоже через аннотации). Или можно чётко проставить диалект (вроде должно помочь и генерировать SERIAL в sql, но не факт).
Кароч, много ньюансов, некоторые постигаются после гугления... Если есть возможность генерить таблицы руками и/или с помощью нормальных инструментов миграции, то лучше использовать их. Если же таблицы часто меняются, то на первое время автогенерация прокатит.
для себя сделал так:
0) на продуктовой и предпродуктовой БД для Hibernate нет прав на изменение схемы. Но есть такие права для Flyway, который уже и управляет изменениями в схеме БД
1) на БД разработчиков у Hibernate права есть полные и hbm2ddl.auto=update. Flyway отключён
Николай Матюшенков: смешанно - что больше подходит под задачу. Можно сразу с нуля написать что-то, а можно посмотреть что Hibernate пытается нагенерить и причесать его желания
Николай Матюшенков: `ddl-auto=update` с правами RW на базу выдаёт в лог строчки, которые можно класть в отдельный лог (или грепать из основного) по регулярке вида ".* SchemaExport:.*: Unsuccessful:.*"
Victor Alenkov: Уточню на всякий случай. То есть чтобы сделать и протестировать подготовленную миграцию, надо делать бекап, накатывать изменения через Hibernate, брать из лога SQL, создавать на основе него миграцию в Flyway. Потом восстанавливать бекап, накатывать миграцию через Flyway. Верно?
Николай Матюшенков: не совсем. Есть тестовый дамп - он и раскатывается. Потом накатывается Flyway (если у него что-то есть) и идёт попытка накатиться в Hibernate - если он что-то выдал, то смотрится вывод, подготавливается ещё один скрипт миграции для Flyway* либо донастраиваются сущности в Java и итерация повторяется.
* тут по ситуации - или редактируется предрелизный скрипт, если можно их "схлопнуть" для оптимизации или добавляется новый