История изменений
Исправление totik, (текущая версия) :
Если есть необходимость так «вылизывать» работу с БД то я бы рекомендовал посмотреть на MyBatis, а не на ORM-ы. С другой стороны есть ли в этом реальная необходимость? Ведь оптимизация <=> увеличение трудозатрат разработчика и, с большой вероятностью, привязка к конкретным «фишкам» именно твоей СУБД. Если это перфекционизм, а не реальная потребность проекта то оно, ИМХО, того не стоит.
Нагенерировала для своего проекта тестовых данных - по 1000 записей на каждую сущность и связь. Что-то еле ворочается, что-то вообще падает исчерпав память. И все из-за того, что при попытке запросить все связанные данные по одной сущности с помощью Named Entity Graph результирующий запрос порождает декартово произведение всех всех связей. При двух списков в одной сущности - это миллион записей. А кое-где их и три и четыре.
Так что лучше я займусь оптимизацией сейчас и буду получать данные самописными JPQL запросами в spring data, вызывая несколько методов, вместо одного с Named Entity Graph.
За MyBatis спасибо! Погляжу на него после этого проекта.
Исправление totik, :
Если есть необходимость так «вылизывать» работу с БД то я бы рекомендовал посмотреть на MyBatis, а не на ORM-ы. С другой стороны есть ли в этом реальная необходимость? Ведь оптимизация <=> увеличение трудозатрат разработчика и, с большой вероятностью, привязка к конкретным «фишкам» именно твоей СУБД. Если это перфекционизм, а не реальная потребность проекта то оно, ИМХО, того не стоит.
Нагенерировала для своего проекта тестовых данных - по 1000 записей на каждую сущность и связь. Что-то еле ворочается, что-то вообще падает исчерпав память. И все из-за того, что при попытке запросить все связанные данные по одной сущности с помощью Named Entity Graph результирующий запрос порождает декартово произведение всех всех связей. При двух списков в одной сущности - это миллион записей. А кое-где их и три и четыре.
Так что лучше я займусь оптимизацией сейчас и буду получать данные самописными JPQL запросами, вызывая несколько методов, вместо одного с Named Entity Graph.
За MyBatis спасибо! Погляжу на него после этого проекта.
Исходная версия totik, :
Если есть необходимость так «вылизывать» работу с БД то я бы рекомендовал посмотреть на MyBatis, а не на ORM-ы. С другой стороны есть ли в этом реальная необходимость? Ведь оптимизация <=> увеличение трудозатрат разработчика и, с большой вероятностью, привязка к конкретным «фишкам» именно твоей СУБД. Если это перфекционизм, а не реальная потребность проекта то оно, ИМХО, того не стоит.
Нагенерировала для своего проекта тестовых данных - по 1000 записей на каждую сущность и связь. Что-то еле ворочается, что-то вообще падает исчерпав память. И все из-за того, что при попытке запросить все связанные данные по одной сущности с помощью Named Entity Graph результирующий запрос порождает декартово произведение всех всех связей. При двух списках в одной сущности - это миллион записей. А кое-где их и три и четыре.
Так что лучше я займусь оптимизацией сейчас и буду получать данные самописными JPQL запросами, вызывая несколько методов, вместо одного с Named Entity Graph.
За MyBatis спасибо! Погляжу на него после этого проекта.