Я с большим удовольствием пользовался Hibernate Tools (примеры приведены на их сайте).
Ниже я приведу подробности моего конкретного, продвинутого и интересного (я думаю) варианта использования.
На самом деле, я столкнулся с интересной проблемой в нашем большом проекте (около 800 таблиц, команда, управляемая базой данных)
- Новые таблицы будут продолжать поступать, поэтому я могу сгенерировать их из базы данных
(используя HibernateTools и создавая аннотированные сущности) (сейчас мы на самом деле используем другой процесс ...)
Но таблицы mosts не были новыми, у меня уже были реализации java и .hbm.xml.
Оба были иногда модифицированы из БД, с которой они были изначально созданы, поэтому было невозможно заново сгенерировать их с гарантией, чтобы ничего не сломать. Мне нужно было перенести сущности, меняя их как можно меньше (то есть только аннотации)!
Это нужно было также быстро, потому что наши типичные старые сущности имеют около 100 членов (собственные столбцы БД, а также коллекции сущностей, полученные из обратных внешних ключей!).
Примечание: две сущности не смогли скомпилировать сгенерированный полный конструктор, они нарушили ограничение в 256 параметров! Но я думал, что этот Конструктор был бесполезен в любом случае, он мог запомнить порядка 256 параметров, поэтому я удалил его.
- Я также хотел перевести мои наборы на общие (кроме сеттера, с которым я сейчас не связывался).
Для переноса сопоставления я использовал Hibernate Tools (настроенные по мере необходимости, шаблон и код) следующим образом:
источником информации были файлы .hbm.xml, с файлом hibernate.cfg.xml
Примечание. Сначала мне пришлось извлечь файл hibernate.cfg.xml, заменив bean-компонент Spring, который раньше содержал список. Но это также было полезно для инструментов db, таких как Squirrel, которые могли использовать его для включения завершения HQL ...
сгенерированный вывод - файлы X2.java (для класса X.java в том же пакете), содержащие только поля, геттеры и аннотации
(без сеттеров или конструкторов) (универсальные наборы)
Я бы использовал компилятор Eclipse (ошибка «duplicate ...»), чтобы перепроверить мое редактирование, сделать его быстрее и менее подверженным ошибкам (ошибка не была возможной, у нас много клиентов в работе!). Для каждого перенесенного класса я бы скопировал из сгенерированного в существующий класс:
- измените persistence.cfg.xml, чтобы использовать класс вместо .hbm.xml
- вырезать и вставлять @Entity перед именем класса
- вырезать и вставлять все поля Set после существующих полей, удалять только те, которые имеют ошибку компиляции (в результате у меня теперь есть поля с универсальными наборами)
- вырезать и вставлять все геттеры (что является остальной частью класса) после существующих сеттеров
- открыть представление структуры, показывая только общедоступные динамические методы, не начинающиеся с 'set', отсортированные по алфавиту
- проверьте каждый получатель, который не имеет ошибки (выясните, не произошло ли что-то не так, или он был сброшен с тех пор ...)
- после представления схемы, учитывая только ошибочные методы, для каждого получателя в порядке:
удалить второй экземпляр метода, скопировать его аннотации в первый экземпляр
(навигация с использованием представления структуры) (порядок методов в классе сохраняется, что было важно для истории CVS, особенно в том, что доказать неверующим, что миграция не сломала их код, она уже была нарушена раньше!).
- ... некоторые детали оставлены для дальнейшего обсуждения ...
Для любопытных, в этом месяце мы близки к 200 аннотированным сущностям :-).
Типичный объект из 100 полей требует около 30 минут работы для переноса.
Осталось только 300 часов, чтобы закончить эту вырезанную пасту для оставшихся 600 объектов! ; -)