Приходилось ли использовать генераторы моделей для работы с базой данных
Что проверяют
Понимаете ли вы, кто в проекте хозяин схемы: база или код. Вопрос кажется про удобство, но за ним стоит эксплуатация, потому что неверный ответ означает, что на проде схему меняет ORM по своему усмотрению.
Как отвечать
Разделите два направления. Схема из кода это генерация таблиц по сущностям, она хороша для наброска и для тестов. Код из схемы это генераторы сущностей по существующей базе: обратная разработка в Hibernate, плагины среды разработки, а в случае jOOQ ещё и типобезопасные классы под каждую таблицу и колонку.
Дальше назовите правило, которое от вас ждут. В проде схемой управляют миграции, Flyway или Liquibase, а hibernate.hbm2ddl.auto стоит в значении validate или выключен совсем. Режим автоматического обновления ничего не удаляет и не переименовывает, порядок изменений не контролируется, а при нескольких экземплярах приложения они ещё и стартуют одновременно.
Если генерация кода всё-таки нужна, встройте её в сборку и генерируйте по той же схеме, что на проде: поднимаете базу в контейнере, накатываете миграции, запускаете генератор. Тогда расхождение между кодом и таблицами ловит сборка, а не пользователь. Сгенерированные классы не правят руками, дополнения выносят в отдельные файлы.
Где спотыкаются
Оставляют автоматическое обновление схемы на бою. Пока изменения только добавляют колонки, всё тихо, а первое переименование оставляет в таблице два поля, причём данные лежат в старом.
Второе: правят сгенерированный класс руками. Следующий запуск генератора стирает правку, причём молча, и пропажа всплывает уже после выкатки.
Третье: берут сгенерированную модель как есть и отдают наружу. Связи получаются жадными, каждый список тянет соседние таблицы, вылезает лишний запрос на каждую строку, а при обращении к связи вне сессии приходит отказ ленивой загрузки. Нужен отдельный слой объектов передачи и явная загрузка нужных связей.