|
|
|
Хибер. Шалит. н+1?
|
|||
|---|---|---|---|
|
#18+
В общем, такая тема. Есть некая сущность скажем, покупан. Есть сущность магазины в которых он был. Мы формируем джейсон дтошку из покупанов с внутренним массивом (у каждого) магазинов где он был. Ну так надо да. суть когда в следующем, мы достаем лист покупанов, потом при формировании дтошки итерируемся по листу покупанов достаем через геттер лист магазинов где он был и перезабиваем этот лист уже в дтошку перебирая каждую сущность и выдергивая из нее нужные поля. Всё происходит внутри одной транзакции. В общем, сделано так как сделано. Ессно генерится чумовое число запросов. если исключить вытаскивание листа магазинов из каждого покупана, то всё становится красиво. ботлнек тут. как я вижу решить это? вариант с голым скл тут не пройдет в силу некоторых обстоятельств. вариант с жпкл тоже как то не видится. значит что остается? выдергивать лист юзеров через хибер, и уже потом имея айдишки юзеров отдельным запросом по каждому юзеру выдергивать те магазины где он был и уже потом эти данные расталкивать в дто. тогда мы получаем количество запросов равное количеству юзеров плюс 1. или это и есть то что происходит сейчас? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2016, 00:33 |
|
||
|
Хибер. Шалит. н+1?
|
|||
|---|---|---|---|
|
#18+
попробую завтра в спецификацию вкарячить это. интересно поможет: root.fetch("магазины", JoinType.LEFT) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2016, 01:05 |
|
||
|
Хибер. Шалит. н+1?
|
|||
|---|---|---|---|
|
#18+
спасибо.. сделал всё-же через жойн фетч (гыгы, узнал что для каунта он не работает, но хиберовская ошибка об этом никогда не скажет, надо включать скилы ванги), количество запросов упало с н+1 до 2-3х, НО ))) по времени примерно как было так и осталось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2016, 20:38 |
|
||
|
Хибер. Шалит. н+1?
|
|||
|---|---|---|---|
|
#18+
natanabrahamjrспасибо.. сделал всё-же через жойн фетч (гыгы, узнал что для каунта он не работает, но хиберовская ошибка об этом никогда не скажет, надо включать скилы ванги), количество запросов упало с н+1 до 2-3х, НО ))) по времени примерно как было так и осталось. индексы есть :)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 18:15 |
|
||
|
Хибер. Шалит. н+1?
|
|||
|---|---|---|---|
|
#18+
Blazkowicz https://docs.oracle.com/javaee/7/tutorial/persistence-entitygraphs001.htm объясните популярно на пальцах в чем суть этого ентити графа? вот не понимаю я этой концепции и парадигмы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 18:16 |
|
||
|
Хибер. Шалит. н+1?
|
|||
|---|---|---|---|
|
#18+
Atum1, Сущности и ассоциации, надеюсь, объяснять не надо? Есть ленивая загрузка. Она хорошо, потому что не нужно грузить всё сразу. Она плохо, потому что догрузка данных создаёт кучу запросов, что намного медленее одного. Есть Fetch Eager/Join, которая быстрее ленивой загрузки за счет меньшего количества запросов, но жрет память. Есть динамическое управление режимом Fetch внутри HQL и Criteria API - суть в том что в каждом отдельном запросе мы можем решить какие ассоциации нам нужны ленивыми, а какие нет, конкретно в этом запросе. Соответсвтенно для разных сценарием нужны разные запросы. Где-то нам нужны только клиенты. А где-то клиенты с заказами. А в другом месте - клиенты с контактами. EntityGraph это вершина эволюции. Она заключается в том что зание о том какие свойства как грузить мы выносим из запроса и именуем: Клиенты-с-Заказами, Клиеенты-с-Контактами. И потом по имени используем эти правила в нужных сценариях, отдельно от запросов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 18:28 |
|
||
|
Хибер. Шалит. н+1?
|
|||
|---|---|---|---|
|
#18+
я тут щас через всё приложение бегаю, фикшу н+1 и могу сказать одно.. игер это вообще для коллекций зло. т.е. я в этом уже в который раз убедился. что зло. оно как то непрогнозируемо работет. допустим, забиваем дтошку из объектов с листами объектов. и ВЕЗДЕ эта фигня где стоит игер (речь о процессе внутри транзакции) генерит н+1. Вроде хотя как бы это наоборот ожидается как замена джойн-фетча. а вот нет. Кроме того, где-то совсем недавно читал, что от игеров ообще предлагают отказаться в контексте связей один-много (коллекции в сущности). По мне так в данном случае самый оптимальный подход - это тотальный отказ от игорей и вменяемое использование джойн-фетчей в спеках (жпкл запросах), где надо. А по графам, если честно, не очень разобрался. Как понял пришлось бы доменную модель подпиливать, а на это думаю никто не подпишется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2016, 22:57 |
|
||
|
Хибер. Шалит. н+1?
|
|||
|---|---|---|---|
|
#18+
[quot Blazkowicz]Atum1, EntityGraph это вершина эволюции. Она заключается в том что зание о том какие свойства как грузить мы выносим из запроса и именуем: Клиенты-с-Заказами, Клиеенты-с-Контактами. И потом по имени используем эти правила в нужных сценариях, отдельно от запросов.[/quo есть обычный sql - jpql -hql есть dto - эти механизмы могут вернуть только то что нужно .... без прокси . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2016, 23:48 |
|
||
|
Хибер. Шалит. н+1?
|
|||
|---|---|---|---|
|
#18+
в графе как я понял, некая "генеричность" преследуется. так то да, жпкл можно всё почти сделать, но они не так глобальны и всегда используются для частных случаев. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.11.2016, 23:50 |
|
||
|
Хибер. Шалит. н+1?
|
|||
|---|---|---|---|
|
#18+
BlazkowiczAtum1, Сущности и ассоциации, надеюсь, объяснять не надо? Есть ленивая загрузка. Она хорошо, потому что не нужно грузить всё сразу. Она плохо, потому что догрузка данных создаёт кучу запросов, что намного медленее одного. Есть Fetch Eager/Join, которая быстрее ленивой загрузки за счет меньшего количества запросов, но жрет память. Есть динамическое управление режимом Fetch внутри HQL и Criteria API - суть в том что в каждом отдельном запросе мы можем решить какие ассоциации нам нужны ленивыми, а какие нет, конкретно в этом запросе. Соответсвтенно для разных сценарием нужны разные запросы. Где-то нам нужны только клиенты. А где-то клиенты с заказами. А в другом месте - клиенты с контактами. EntityGraph это вершина эволюции. Она заключается в том что зание о том какие свойства как грузить мы выносим из запроса и именуем: Клиенты-с-Заказами, Клиеенты-с-Контактами. И потом по имени используем эти правила в нужных сценариях, отдельно от запросов. В чем отличие от https://docs.jboss.org/hibernate/orm/3.5/javadocs/org/hibernate/StatelessSession.html и того что я пишу точный запрос и вытаскиваю только то что мне нужно через dto или через Чистый sql joql hql? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2016, 21:07 |
|
||
|
Хибер. Шалит. н+1?
|
|||
|---|---|---|---|
|
#18+
Atum1В чем отличие от https://docs.jboss.org/hibernate/orm/3.5/javadocs/org/hibernate/StatelessSession.html Как в пустоту писал. :( Это сессия без состония. К вопросу отношения не имеет. Atum1и того что я пишу точный запрос и вытаскиваю только то что мне нужно через dto dto вообще для другого нужны. Atum1или через Чистый sql joql hql? Тем что во всех случаях тебе нужно написать запрос. А в полноценном ОРМ - не обязательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.11.2016, 21:42 |
|
||
|
|

start [/forum/topic.php?fid=59&tid=2123494]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
156ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
38ms |
get tp. blocked users: |
1ms |
| others: | 243ms |
| total: | 478ms |

| 0 / 0 |
