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

вопрос такой. у меня есть допустим, сущность человек. у него есть ссылка на адрес. человек это таблица с фк адреса. адрес это тоже таблица мне надо вытащить объект вида
class Peep(field:String, field2:String, field3:Option[Address]) -- вроде банально и просто для хибера. но как делать это в слике (нормально) я не понимаю

можно по тупому из дб.ран выдрать через тейблПипКвери джойн тейблАддресКвери сущности вида в трейте (peep, address) потом каким-нибудь маппером их склеить в peepWithAddress но это как то через зад.

ну ок.. даже так.. а если у меня будет трейт из 5-8-10-ти объектов? да это ж бред.

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

сама сущность выглядит так:

class EntityA(
fieldA:String,
...
fieldZ:String,
entityB:Option[EntityB],
entityC:Option[EntityC],
entityD:Option[EntityD],
entityE:Option[EntityE],
entityF:Option[EntityF],
)

да. он очень ужасен. в хибере это одна строчка. а тут гамно какое то.

зы (имена изменены) если по неймингу претензии. хотя думаю нет.

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

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

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

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

авторThe problem is that this hard-codes that a Person requires an Address. It cannot be loaded without it. This doesn’t fit to Slick’s philosophy of giving you fine-grained control over what you load exactly. With Slick it is advised to map one table to a tuple or case class without them having object references to related objects. Instead you can write a function that joins two tables and returns them as a tuple or association case class instance, providing an association externally, not strongly tied one of the classes.
т.е. они считают это НОРМАЛЬНЫМ. можно переложить тапель на сущность. это чуть улучшит картинку но всё-равно говно. еще прям везде читается если тебе такая конструкция понадобилась то ты делаешь что-то не так.

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

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

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

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

по-моему andreykaT тупо тролит... я вот беру хибернейт, и у меня просто нереально бомбит от того, как в нем сделаны некоторые, не особо популярные места
и что в хибере не так? у тебя сущность а с 3-4-мя нестед сущностями у тебя будет запрос в РОВНО ОДНУ СТРОЧКУ записанный кемелкейсом в интерфейсе. даже аннотаций не надо. и тебе вылетет сущность со всеми нестедами внутри.

а да если что код не мой но я хочу его отрефачить.

maytonВ Java Tuples в реализации https://howtodoinjava.com/java/basics/java-tuples/ разрешено 10 сущностей в тупле.
Да фигня это всё. По хорошему если тебе надо нечто больше чем Pair - бери создавай сущность. Или чухай в Lisp.

Зачем сову сношать глобусом?
ты можешь его сделать так: .map(EntityWithNestedEntityFields.tupled) - и он у тебя соберет всё в одну сущность.. но тебе же это надо писать и всё-равно у тебя в какой-то момент времени будет вылетать колбаса из тупла с объектами.

http://slick.lightbend.com/doc/3.2.0/orm-to-slick.html



ну в общем, сверху это вполне по-сликовски православно )) просто у них нет примеров с мультиджойнами ))

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

maytonНу... туториал нормален. Там нет такого code-mess...

потому что там нет примеров где джойна больше 1 а так и я могу

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

но вот в слике банальное персона с адресом уже не вытащить нормально

ну и пусть. тебе жалко чтоле? лейзи опасны на списках. а на единичных нестедах да пофиг у тебя скорее ботлнек случится где угодно но не тут.

в общем возвращаясь к слику.. это как-то можно улучшить? )

*т.е. не лейзи а отсутствите лейзи - и.е. игеры опасны на списках. на полях с одной сущностью игеры фигня.