Hibernate 5: reverse engineering + custom naming strategy

начала реверсить базу

удачи и терпения тебе, расскажи если/когда получится

а мы обычно пишем базу для кода, а не наоброт, поэтому таких проблем пока не было

удачи и терпения тебе, расскажи если/когда получится
а мы обычно пишем базу для кода, а не наоборот, поэтому таких проблем пока не было

Везет вам, если по работе делаете только то, что хотите. А у других, менее везучих коллег, бывают такие задачи, когда необходимо использовать уже существующую инфраструктуру.

Подскажите как быть =)

вообще если корявая база есть то под нее имеет смысл заюзать sql темплйты с маппингом - типа mybatis (если он жив)

если же хочется хлебать orm ложкой, то на любой сучности ты можешь указать имя таблицы в соответствующей аннотации, ну да это манулаьный рефакторинг после реверсинжиниринга, но кто обещал что будет легко?

База в процессе разработки и периодически нужно будет синхронизироваться. Не хотелось бы раз в неделю заниматься тупым ручным трудом. К тому же существующая проблема когда-то легко решалась с помощью DelegatingReverseEngineeringStrategy.

он реализует интерфейс ReverseEngineeringStrategy качай сорцы тузлы и ищи по ним где эта штука ищется и как инстанцируется

ps. беглый осмотр показал что скорее всего оно конфигурирется в JDBCMetaDataConfiguration

Я разобралась. Вот лохушка =) В самом hibernate tools указывается rev.eng. strategy. Все работает как надо с минимумом кода. Всем спасибо.

кроме везения, это еще целенаправленная работа по пропаганде правильной (удобной для нас) культуры делать определенные вещи. Например, если долго (годами) повторять заказчику, что использовать SQL нужно только на критичных по перфомансу задачах, а в остальных случаях - ORM, и этот совет постоянно подтверждаться реальностью, через некоторое время заказчик уже и забывает, что можно как-то по-другому, это становится его личной идеей

но тут такое, я конечно в основном участвовал не в поддержке, а именно что в рефакторинге. Когда заказчик приходит с куском ада, написанным вечнопьяными индусами, и говорит: а чойта добавление пункта меню занимает у разрабочика две недели. А мы такие - ну так потому что база - говно, лютейшие SQL на ровном месте, давайте мы вот тут кусок удалим к чертям и за две недели на ORM с нуля перпишем. И так кусочек за кусочком - embrace, extend and extinguish

типа mybatis (если он жив)

ох лол, мы тут недавно перешли на работу с базой с помощью Freemarker. Потому что нереляционные портянки, поэмы «как я провел лето пытался изобразить, что база хотя бы иногда консистентная». Думаю еще код на JS начать генерить на Фримаркере. После чего заменить в резюме слово «джава» на слово «фримаркер» и начать рубить бабло с доверчивых простаков, bleeding edge technology жи

База в процессе разработки и периодически нужно будет синхронизироваться.

нужно чтобы java-частью управления базой, и самой базой, занимался один и тот же человек. Тогда ему не придется синхронизироваться - сделает новую таблицу, тут же нафигачит ее отображение в джаве, и наоборот

нужно чтобы java-частью управления базой, и самой базой, занимался один и тот же человек. Тогда ему не придется синхронизироваться - сделает новую таблицу, тут же нафигачит ее отображение в джаве, и наоборот

Когда начинаешь разрабатывать проект с нуля и можешь принимать решения, бесспорно. Когда даже не подключаешься к разработке основной системе, а просто используешь чужую сформированную инфраструктуру, подобные советы бессмысленны.

если тебе сказали - «у нас есть свои разработчики, они будут пилить базу и только базу» - просто отказываешься от такого проекта, пусть сами месят свою глину

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