Let�s say I have hotel with one to one to room and room has one to one to roomDetails.
When I ask for hotel, I don�t need roomDetails, so the relation between room to roomDetails needs to be lazy. But, when I ask for room I need the roomDetails so I need that the relation will be eager.
In this example it simple, but in my application I have a lot of references that point to more references and etc. I look on the query that hibernate execute when it try to load object AAA and found that it has 31 left outer joins, I don�t need some of those references when i load AAA , but I cant map them as lazy because I need them if I load object BBB or CCC that is referenced from AAAA.
OK, I like this post than your other thread because you have the perfect examples to use to demonstrate.
OK, so you listed more than one use case. One where you want it all Lazy and one where you wnat it eager loaded.
And this is why we always say.
Make all the mappings lazy. And in your Use cases make your Queries be eager when you need them to be. It is use case driven, each individual use case should, in the query, set the fetching modes required.
Meaning when you create a Criteria or Query you can tell Hibernate on any join to make it an eager one (setFetch() or "eager join") .
Originally posted by avihai marchiano: I know about the fetch strategy.
My facade is generic and my object graph is not so simple like in the example
so i don�t have special queries i just run entitymanager.find
i don�t want to write for each entity in my application special loading.
apparently as I see there is no magic for this issue, so i will need to write logic for some of the entities
OK, while I disagree with your architecture there for an application. Here are your options.
In all cases you have to keep from fetching more data than each use case needs. If I ask for a Hotel and don't need RoomDetails for this use case, why query for it.
1) Keep everything lazy, (There is a reason why everything is lazy by default in Hibernate). When you do a find, there will be no associated objects. While still having that current session open, when your app actually needs the associated objects, then call the getters and let Hibernate run another query to get the next object, (with Collection mapping, you will get the N+1 problem.
2) Keep everything lazy, except for Collections, for them map the fetch to be "subselect" What this does is stop the N+1 problem and make it 1+1 or two queries. The first query to load the Hotel, and another query to load all the RoomDetails the moment you call getRoomDetails (again within the same Session)on the Hotel object. That second query will actually have the first query as a subselect, so that in one query you get back all the RoomDetails for the Hotel.
I think you will find you are better off with option 2.
I can guarantee that you will hate the performance of you app if you make every thing or most things eager mapped.