История изменений
Исправление totik, (текущая версия) :
Да, я оговорилась, не только списки, но и множества.
Использование Set не избавляет от декартового произведения в результирующей таблице sql-запроса. Все равно нужно будет выкачать те миллиарды записей, что подготовит СУБД и потом уже провайдер JPA все разложит по сетам.
Так что я отказалась от вытягивания связей OneToMany и ManyToMany больше одной за раз.
Если вручную формировать сущности на кастомных запросах все гораздо эффективнее можно написать, чем то, что предлагает. JPA/Hibernate.
Исправление totik, :
Да, я говорила что, не только списки, но и множества.
Использование Set не избавляет от декартового произведения в результирующей таблице sql-запроса. Все равно нужно будет выкачать те миллиарды записей, что подготовит СУБД и потом уже провайдер JPA все разложит по сетам.
Так что я отказалась от вытягивания связей OneToMany и ManyToMany больше одной за раз.
Если вручную формировать сущности на кастомных запросах все гораздо эффективнее можно написать, чем то, что предлагает. JPA/Hibernate.
Исправление totik, :
Да, я говорила что, не списки, но и множества.
Использование Set не избавляет от декартового произведения в результирующей таблице sql-запроса. Все равно нужно будет выкачать те миллиарды записей, что подготовит СУБД и потом уже провайдер JPA все разложит по сетам.
Так что я отказалась от вытягивания связей OneToMany и ManyToMany больше одной за раз.
Если вручную формировать сущности на кастомных запросах все гораздо эффективнее можно написать, чем то, что предлагает. JPA/Hibernate.
Исходная версия totik, :
Использование Set не избавляет от декартового произведения в результирующей таблице sql-запроса. Все равно нужно будет выкачать те миллиарды записей, что подготовит СУБД и потом уже провайдер JPA все разложит по сетам.
Так что я отказалась от вытягивания связей OneToMany и ManyToMany больше одной за раз.
Если вручную формировать сущности на кастомных запросах все гораздо эффективнее можно написать, чем то, что предлагает. JPA/Hibernate.