Доброго времени суток!
Есть проблема: есть куча кода в котором везде используется EAGER загрузка.
Судя по всему это было сделано для верхнего уровня.
Вопрос: можно ли как то для логики работающей на среднем уровне все запросы сделать ленивыми?
те все сущности оставить как есть — переделывать уже нельзя
Здравствуйте, alexey.a.semenov, Вы писали:
AAS>Только что приходит на ум:
AAS>The static methods Hibernate.initialize() and Hibernate.isInitialized(), provide the application with a convenient way of working with lazily initialized collections or proxies. Hibernate.initialize(cat) will force the initialization of a proxy, cat, as long as its Session is still open. Hibernate.initialize( cat.getKittens() ) has a similar effect for the collection of kittens.
AAS>p.s. а может все таки open session in view? хотя не настаиваю
или я плохо описал ситуацию или ...
я хочу наоборот не делать полную загрузку
сейчас она делается полная
Здравствуйте, kokaku, Вы писали:
K>я хочу наоборот не делать полную загрузку сейчас она делается полная
Если через Criteria API не выходит, то скорее всего никак.
K>Вопрос: можно ли как то для логики работающей на среднем уровне все запросы сделать ленивыми?
K>те все сущности оставить как есть — переделывать уже нельзя
Если я тебя правильно понял
Programmatically override or completely redefine fetching at runtime through API and queries:
Criteria respects the laziness settings in your mappings and guarantees that what you want loaded is loaded. This means one Criteria query might result in several SQL immediate SELECT statements to fetch the subgraph with all non-lazy mapped associations and collections. If you want to change the "how" and even the "what",
use setFetchMode() to enable or disable outer join fetching for a particular collection or association. Criteria queries also completely respect the fetching strategy (join vs select vs subselect).
HQL respects the laziness settings in your mappings and guarantees that what you want loaded is loaded. This means one HQL query might result in several SQL immediate SELECT statements to fetch the subgraph with all non-lazy mapped associations and collections. If you want to change the "how" and even the "what", use LEFT JOIN FETCH to enable outer-join fetching for a particular collection or nullable many-to-one or one-to-one association, or JOIN FETCH to enable inner join fetching for a non-nullable many-to-one or one-to-one association. HQL queries do not respect any fetch="join" defined in the mapping document.
At the moment no batch or subselect fetching override is available dynamically. Both Criteria and HQL respect the settings defined in the mapping document if additional SELECT statements must be executed to load the non-lazy mapped associations and collections.
Здравствуйте, kokaku, Вы писали:
K>Доброго времени суток!
K>Есть проблема: есть куча кода в котором везде используется EAGER загрузка.
K>Судя по всему это было сделано для верхнего уровня.
K>Вопрос: можно ли как то для логики работающей на среднем уровне все запросы сделать ленивыми?
K>те все сущности оставить как есть — переделывать уже нельзя
В свое время я работал на похожем проекте, где было решено сделать все сущности EAGER (может оказаться, что ты на этом же проекте, так как именно сейчас как раз набор на него
). Так вот — если это тот самый проект (JSF, Spring Web Flow, BPM а также самописный фреймворк валидации как плагин к эклипсу, этот мегафреймворк ни с чем не спутать
), то никаких LAZY там ставить ни в коем случае нельзя! Ставить, и принудительно дергать — не выход, года 4 назад так делали — но слишком велика вероятность пропустить какую связь, в результате что может упасть в произвольном месте, а кода до черта. Потому я б рекомендовал оставить как есть. Но, когда требуется вернуть из базы какой то небольшой кусок, а не все огроменное дерево, на которое не хватит никакой памяти — просто доставать DTO. А запрос на получение этой DTO (в том числе сложной и древовидной) генерить самому — написать автогенератор запроса не так сложно. Если реализовать нормально — получится вполне красивое и достаточно грамотное решение, несмотря на то, что от EAGER уже не избавиться. Да и если б LAZY оставили — один черт бы пришлось на DTO переходить, но просто с другой стороны.
