VP
Понятное дело, там будет логика лазания в бд, сгенеренная ОРМ, но это не логика работы с данными:)
Не всем объектам суждено быть тру-объектами как завещал Егор
Size: a a a
2019 August 06
АО
В бинах тоже никакой логики, они от этого перестают объектами быть?
Есть объект, есть структура (дата класс в котлине), разница в наличии логики работы
AE
@Harmonizr а как хранить списки других объектов в строке таблицы бд?:)
1:м референс хранится справа. м:м посередине возникает третья таблица с референсами в обе стороны
AO
Не всем объектам суждено быть тру-объектами как завещал Егор
Ага, пока не начинаешь использовать кеш второго уровня и не надо его инвалидировать
AE
Честно, лучше ручками написать
нет
BV
Ага, пока не начинаешь использовать кеш второго уровня и не надо его инвалидировать
Обычно это плохая идея
AE
А можно ли оперируя объектами объяснить фреймворку, что в итоге нужно вытащить из базы или обновить там, не делая лишних запросов?
да
BV
Есть объект, есть структура (дата класс в котлине), разница в наличии логики работы
И? Ну, ладно, это не объекты, а структуры, что от этого меняется?
AE
У нас из-за такого хибер сделает сам на 1:M появился ботлнек, потому что внезапно надо было дёрнуть у 1000 объектов lazy поле c 1:M
делается join fetch и вытаскивается одним запросом
АО
И? Ну, ладно, это не объекты, а структуры, что от этого меняется?
Ну кроме этого ничего:)
BV
Ну кроме этого ничего:)
Т.е. и смысла обсуждать не было
АО
Т.е. и смысла обсуждать не было
1. Мы выяснили, что одна строка в таблице - не объект
2. Мы выяснили, что объекты орм без логики - не объекты
3. Пришли к какому-то заключению
2. Мы выяснили, что объекты орм без логики - не объекты
3. Пришли к какому-то заключению
VP
Ну и как?
Вот хочу я сделать
Вот хочу я сделать
user.orders.filter { it.date.year == 2019 }.sumBy { it.total }BV
У нас из-за такого хибер сделает сам на 1:M появился ботлнек, потому что внезапно надо было дёрнуть у 1000 объектов lazy поле c 1:M
Так это же решается родными средствами, можно даже динамически тип фетча менять
AE
Условие не дублирования - это про что?
у тебя есть 2 таблицы, они связаны через map таблицу как м:м, при джойне справа строки будут повторяться для разных строк слева, в рантайме у тебя это должен быть один объект, а не дубликаты с одинаковым содержимым. в обратную сторону так же
BV
1. Мы выяснили, что одна строка в таблице - не объект
2. Мы выяснили, что объекты орм без логики - не объекты
3. Пришли к какому-то заключению
2. Мы выяснили, что объекты орм без логики - не объекты
3. Пришли к какому-то заключению
Мы выяснили лишь то, что мы по разному слово объект понимаем. Не большое достижение
AO
делается join fetch и вытаскивается одним запросом
Это делается уже отдельными запросом, а тут у тебя есть 1000 объектов, которые просто достали из БД. Решилось в итоге это всё навешиванием какой то там аннотации на поле, которая говорила, возьми и вытяни заодно для такого количество объектов из кеша это поле
AO
у тебя есть 2 таблицы, они связаны через map таблицу как м:м, при джойне справа строки будут повторяться для разных строк слева, в рантайме у тебя это должен быть один объект, а не дубликаты с одинаковым содержимым. в обратную сторону так же
да вроде нет никаких проблем, HashMap и в продакшен
VP
у тебя есть 2 таблицы, они связаны через map таблицу как м:м, при джойне справа строки будут повторяться для разных строк слева, в рантайме у тебя это должен быть один объект, а не дубликаты с одинаковым содержимым. в обратную сторону так же
А такое разве можно сделать нормально одним запросом? Ну то есть стоит ли вообще делать джоин?
AO
А такое разве можно сделать нормально одним запросом? Ну то есть стоит ли вообще делать джоин?
лучше конечно за 2 это сделать