Инструменты Hibernate и постоянно меняющаяся база данных

Question

Я сейчас использую Hibernate Tools 3.1; Я настроил соглашение об именах и шаблоны DAO. База данных (SQL Server 2005) находится на ранней стадии разработки, и я отвечаю за восстановление сопоставлений, сущностей, DAO, конфигурации и т.д. Каждый раз, когда мне приходится перепроектировать таблицы, я теряю все настройки, которые я сделал для сопоставлений (файлы * .hbm.xml), например, для настройки столбцов identity , выбор полей, используемых в , равен и toString . Я думал о том, чтобы записать diff XML в файл и «объединить» это с созданным отображением (см. мой связанный вопрос ), но мне было интересно ... есть ли лучший метод / инструмент для работы с эти раздражающие, неизбежные, критические задачи?

Answer 1

Я бы настоятельно рекомендовал против постоянного реверс-инжиниринга. Обратный инжиниринг - отличная вещь, но изменениями нужно управлять как изменениями в hbm и базе данных.

Мы используем миграции для управления изменениями в БД и включаем соответствующие изменения в hbm. Если он есть в Hibernate (я полагаю, что он есть), вы можете использовать аннотации вместо hbm, их легче поддерживать.

Answer 2

Это два с половиной года позже, но я выскажу особое мнение. Вы должны иметь возможность вносить любые необходимые изменения в файлы сопоставления с помощью файла hibernate.reveng.xml или пользовательской ReverseEngineeringStrategy. Для самих классов вы всегда должны генерировать базовые классы и расширять их классами, содержащими пользовательский код.

Например, сгенерируйте com.company.vo.generated.CustomerGenerated и добавьте его с помощью com.company.vo.custom.Customer. Генерация кода должна перезаписывать все классы в сгенерированном пакете, но не в пользовательском пакете (хотя Hibernate Tools может создавать эти пользовательские классы в целевом каталоге, чтобы вы могли копировать и вставлять пробелы в пользовательский каталог по мере необходимости). Таким образом, вы можете переопределить методы для equals, toString и т. Д. В пользовательских классах и не потерять свои изменения при регенерации. Также обратите внимание, что рекомендуется не проверять сгенерированный код в SCM.

На этом сайте есть несколько замечательных примеров того, как этого добиться, используя Maven, плагин Hibernate3 и плагин build helper. У большинства из них есть очень полезные ответы Паскаля Тивента. Этот метод прекрасно работает для меня, и хотя есть некоторая кривая обучения, замечательно иметь возможность распространять изменения базы данных в приложении с помощью одной команды Maven.