a) не связывайтесь с агенствами — зачем вам посредник который долбит компанию и пытается продать вас за +10-20% вашей зп каждый месяц в течении 1-2 лет, в таком случае компании вообще выгодно вас уволить на испыталке что бы не платить агенству

Из своего опыта или теоретически? Как-бы если не формошлепство, а натуральное АйТи, то выхлоп от найма начнется намного позже испытательного срока. А 10-20 процентов — это мелочи по сравнению с поиском новых сотрудником, и потерей времени на уволенного. Знаю людей вполне довольных работой через агенства, так что сомнительная рекомендация в целом (сам не пробовал).

в) не релокейтесь из украины в какую то ноунейм компанию — большие компании с именами не будут вас кидать.

Всякое бывает. Большим компаниям с сильным брендом и командой юристов кидки сходят с рук проще, так что не уверен в универсальности совета. Но в среднем может и поменьше риски.

Собственно неизменяемость это хорошо, но это хорошо для дата-классов, которые есть в Скале и Котлине, а в джаве нету.

 то есть, в Котлине и Скале можно продолжать анемичную модель использовать, а в Джаве нет? А если Джава с Ломбоком?

Наблюдения по Голландии.

В новых жилых домах хорошая изоляция — вроде особо кондиционер не нужен. Ну в самые жаркие дни лучше окна в жаропек прикрыть.

В старом жилом фонде похуже, бывает ставят кондиционер. Сложность с внешним фасадом, т.к. любое изменение должно согласовываться с гементой (ратуша).

В современных офисах нормальное централизированное кондиционирование. В старых домиках на каналах Амстердама может быть похуже, работал одно лето без кондиционера. Жить можно, особенно на нижних этажах или в саду, но на верхних этажах не понравилось.

Вопрос можно? Что за язык показывается в примерах. Как-то непонятен немного контекст.

Чему схлопывание Скалы хорошая иллюстрация.

100%. Но базу в любом случае понимать нужно в нетрививальных приложениях — от этого никуда не деться. А Хибернейт — это дополнительный уровень, и непростой. Если можно избежать — хорошо.

Какие такие механизмы нагрузки базу встроены в нем?

Бездумный lazy loading, выгрузка больших коллекций связанных объектов, поощрение безумных джойнов. При разумном использовании можно наверняка было бы вырефакторить и с хибернейтом, но с этим проблемы две. Первое — мало людей, которые хорошо знают и умеют пользовать хибернейт, по крайней мере в моем контексте. Второе — хибернейт очень много позволяет, вырефакторивать потом тяжело.

Oracle -> postgres несколько раз. Без всяких ORMов относительно легко перевелось, благо концептуально близки со стороны клиента. Алгоритм был обычно: обложили интеграционными тестами с докеризированной базой ORA, вынесли всю логику и триггеры из базы в код приложения, добавили поддержку PG (пару отличий параметризируются JDBC url), добавили в билд докеризированный PG с теми же тестами, готовы к миграции. Дальше или даунтайм с копированием данных или теневой запуск, синхронизация данных например Кафкой, отключаем ORA.

Пару раз выбрасывал Хибернейт, после чего в релиз OPSы прибегали роллбекать требовали — слишком малая нагрузка на базу. Один раз таки пришлось роллбечить, так как заработало слишком быстро.

Не факт, что айдишки, может натурально строки, как в log-файле, foreign key все равно не будет.

Хибернейт тут роли не играет.

И не все сразу приходят к идее ставить флаг удаления, некоторые физически записи удаляют.

Хибернейт тут тоже не поможет, пока не задумаются. Ну разве что доку читать будут и озадачатся.

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

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

А теперь давайте возьмём мой пример из статьи: Order-Client-Item-Quanity. И представим, что трекать нужно каждый чих.

такое бывает? Никогда не видел чтобы созданный ордер менялся / удалялся после того как засубмишен. Это по законодательству недопустимо. Отменяться / статус меняться может, но это другие транзакции. ИМХО пример очень плохой.

1й уровень это сессионный. Он по идее между запросами не шарится? Я имею ввиду внешние запросы, скажем веб.

ОК, аудит — хороший вопрос.

Потому как аудит бизнесу удобный нужен, не «orderId: 235, clientId: 111 -> 222», а понятный «Заказ 235, клиент: Петя -> Вася», плюс иногда понятность для бизнеса может отличаться от объектной, т.е. технически это изменение child-а, но записываем его как изменение parent-а.

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

Теперь по делу. Когда нужно отслеживать изменения, то таки да — лучше это делать явно на уровне домена. сильное ИМХО.

Хибернейтовский @Audited — штука полезная, но больше для прикрытия формальных требований аудита, чем бизнес требований. Работать с его данными не удобно. ИМХО. Могу ошибаться, может можно оттюнить.

В моей практике изменения приходят трекаемыми и линкуемыми командами, большая часть данных append only, немногочисленные изменяемые поля проверяются на изменение еще бизнес-логикой, до персистентности, и трекание их не составляет проблем. Плюс внешние системы типа Кафки для хранения и поглощения истории всеми заинтересованными.

Но это специфика, засчитываю себе аудит как потенциальный плюс Хибернейта, особенно для более CRUD приложений.

Вы в другой ветке ломаете копья, какой инструмент лучше, и вполне может быть, что для ваших задач stateless jooq, jdbc templates и т.д. предпочтительнее.

doesn’t compute to me :) у вас что, хибернейт объекты между запросами в памяти висят?

Что значит

stateful

в данном случае? У меня сервисы stateless, state — он в базе.

Завтра нагрузка на ваше приложение повысилась, а послезавтра оно вообще станет распределенным, и внезапно, необходима синхронизация транзакций на данных.

уже вчера

Самый просто способ, которым это сделаю я — это
em.find(id, timeout, PESSIMISTIC_READ);

Оптимистические локи все-ж предпочтительнее будут при повышенной нагрузке. Разве что у вас высокий уровень contention по одному ключу. Но допустим.

А вы? Ой, это ж надо везде начинать сиквель переписывать на разные SELECT FOR UPDATE, да?

Да. Соглашусь, может быть неудобством. Хотя при переходе между типами локов в существующем высоконагруженном приложении — это будет самой маленькой проблемой.

Потом коммититься явно, да?

Коммит это проблема? или диплоймент? У вас уровень изоляции в конфиге лежит? Нас с вами явно не попути :)

А если у нас логика в разных методах, то Connection из метода в метод передавать, да?

Spring. @Transactional. Походу тоже самое будет с Хибернейтом — от транзакции никуда не денешься с пессимистическим локом, поэтому и мене желательный подход. Старайтесь держать эту транзакцию как можно уже, очень нежелательно вшеншие вопросы.

А там же везде чекед SQLException и вавилонские зиккураты из try { try { try { } catch catch catch.

про работу с сырым JDBC — это ты сам себе придумал. В спринге с эксепшинами проблем нет. В котлине и подавно.

Ребята, маппинги — это не проблема, честно. И это не то, в чем сила Хибернейта.

По батису — пользуем. Не очень. Зачем еще лишнюю xml прослойку, когда можно прямо в коде репозитория держать?

Плюс у него прокси глюкавые.

Да, потому что архитектор уверен что «хибернейт тормозит» :)

и чем закончился эксперимент? Опередили?

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

одна строчка на изменение одного поля. Ничего для полей и сущностей уходящих в jsonb или xml, но за это своя цена поддержки схемы в коде.

А как вы миграции к базе делаете? Из хибернейтной схемы генерите? Данных наверное не очень много?

И он же самый примитивный и громоздкий из доступных на сегодня способов решить ту же задачу

в чем громоздкость? В том, что маппинг не аннотацией статически на доменном объекте, а потенциально динамически также простой строчкой в БД маппере, где ему и положено по-хорошему быть?

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

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

и да, я таки не сильно понимаю чем принципиально

@Column(name = "name")

name = rs.getString("name")