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.
Good Luck
Mark