maytonЯ очень уважаю Scala. Но этот код - unsupportable. Как его читать? Как вносить изменения?
Где бизнес сущности? Что это за нелепое нагромождение подчеркиваний?

Подозреваю что данный запрос на целевом DSL(SQL) был бы красив и компактен.

Скала конечно это тот еще универсал. Но иногда ребята перегибают палку. Хотел-бы
я понят мотивации к писанию такого.

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

andreykaTи что в хибере не так?
впечатление такое, что куда не плюнь - везде какие-то грабли находятся.
andreykaTу тебя сущность а с 3-4-мя нестед сущностями у тебя будет запрос в РОВНО ОДНУ СТРОЧКУ записанный кемелкейсом в интерфейсе. даже аннотаций не надо. и тебе вылетет сущность со всеми нестедами внутри.Насколько я помню, вышеупомянутый пример от скалы можно выполнить только в хибере 5.1 и более поздних версиях ( Entity joins (or ad hoc joins) ) - кажется несколько странным что вроде как разумная фича появилась сравнительно недавно... а вот в JPA Criteria API так сделать до сих пор нельзя - нужно в сущностях прописывать маппинг, а после этого начинается неполовая ##ля с тем, что имбецилы из redhatхибернейт считает себя самым умным и начинает все эти сущности из маппинга на каждый чих тянуть из базы, собственно если захочется в хибере подкрутить производительность до уровня "я так вижу", то будет уйма незабываемых впечатлений.

andreykaTюзай проекции. они тебя спасут. если тебе не нравится что хибер что-то лишнее на твой взгляд вытягивает.

Ничем оно не поможет. Вот сущность:




там FetchType.LAZY работать никогда не будет, потому что так устроен хибернейт. Предлагаю дальше тему не развивать, поскольку примеров масса и хибернейт - это УГ, факт.

Озверина почему тут работать не будет? Я думал проблемы с onetoone ?ну OneToOne - известная грабля, решается обещанием что запись есть при помощи optional=false, однако, lazy в ManyToOne/OneToOne с натуральным ключем при наличии суррогатного не умеет, ну просто потому что в сессии сущности только по одному ключу доступны: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/EntityType.java#L461

Озверина потом меня спрашивают, почему я могу предпочесть запросы сущностям со связями.Ну это только одна из проблем, а там их горы, вот примеры:

захотел в старом хибере чтобы он мне Stream возвращал вместо списка, начал смотреть как реализовали в новом: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/internal/ScrollableResultsIterator.java - збс, в итераторе вызов hasNext() курсор двигает сколько угодно раз

захотели блокировки в нужных местах делать, вроде паттерн стандартный: блокируем запись по id, потом обновляем сущность из БД, а вот нельзя так если в сущности есть @Version-поле - это поделие зачем-то в запрос условие на штамп версии вставляет: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/lock/PessimisticWriteSelectLockingStrategy.java#L111

ну и в общем так постоянно: чуть в сторону от элементарных вещей и сразу грабли на ровном месте.

ПылинкаЗачем блокировать пессимистически, если там автоматом оптимистическая блокировка встроена?не автоматом, а костылем. Оптимистичная блокировка полезна в довольно ограниченных случаях, а именно когда пользователь пытается сохранить строку, а мы его отшиваем и говорим: тут пока ты думал что-то поменялось, иди и разбирайся сам что произошло, в остальных случаях пользы от нее никакой: ну на кой черт нам что-то обрабатывать, а потом в коммите словить ошибку, что не получилось? мы же наверняка знаем что будем менять, поэтому на порядок проще заблокировать то что нужно, а потом уже обновлять. С хиберовским же подходом, получается так, что он пуляет кривой select for update в базу, не получает результата и кидает StaleObjectStateException, от которого толку вообще никакого нет, вот что с ним делать? Ловить в цикле пока не пропадет? а как понять что вообще случилось? Ситуация что строчки в базе нет может быть вызвана по крайней мере тремя причинами, нам еще каждую гипотезу проверять и тоже перехватывать исключения? Вот на ровном месте получается куча стремного кода.

забыл никЗачем тогда вообще использовать Version?Без @Version пользаки будут данные друг друга тихо перетирать, если вы предлагаете вместо @Version пилить что-то свое, то это опять же будет камень в сторону хибера.

забыл никНо пессимистичная используется когда высокий шанс коллизии, а если такой шанс есть, то имеет смысл использовать пессимистик-лок ВСЕГДА, как-то у меня картина не сходится. Это не в укор, хоть я и повидал много бизнес-доменов, но такое вижу впервые, поэтому и интересно узнать в каких случаях такое бывает.Ну сначала вы придумали уловное разделение на пессимистичные/оптимистичные и всегда/невсегда, а теперь пытаетесь заставить меня обосновать такое разделение, ну давайте попробуем.

разделение на всегда/невсегда неверное, просто потому что при записи (обновлении) в базу блокировка возникает всегда и длится от момента когда мы захватили строку до коммита/отката транзакции, правильно здесь делить на явные/неявные. Поэтому если мы на 100% уверены, что вот в этом определенном месте мы будем писать в базу (к примеру от пользователя пришел запрос на обновление), какого-либо смысла не ставить блокировку нет - она так или иначе возникнет, вопрос здесь только в том когда она возникнет, и вот здесь уже начинаются нюансы, а именно:
- база позволяет "подсмотреть" заблокирована строка, которую мы собираемся обновлять или нет, соответственно если мы пытаемся поставить блокировку сразу, то у нас есть возможность указать сколько времени вообще ждать, чтобы не обламывать нашего любимого пользователя, а "сразу" сказать что ждать тут нечего
- если мы явные блокировки там где нужно не ставим, то начинаем ловить лулзы уже из-за неявных (там всякие автофлаши и пр.) - и здесь уже никаких таймаутов нет, и соломку не подложить

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