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

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

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

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

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

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