You don't want to use lazy initialized collections? Then just define them as FetchType.EAGER. If you want a better approach, you can use them lazy implementing OpenSessionInViewpattern, which will load them once you try to access it in code. I don't know if it can be implemented without hibernate, though.
Yes, though you are still using lazy initialization there you are just manually forcing it to initialize. So its no different from just accessing a property on the lazily loaded association, because that will cause the proxy to be initialized. If you know you want the associated object then I'd suggest you eagerly fetch it as part of your query.
Cameron Wallace McKenzie
,
author and cow tipper
staff
Really, if you need the associated objects, fetch them eagerly, if you don't, leave them with the default of being loaded lazily. But dont' make them lazy if you KNOW that you are going to be fetching them anyways.
Eduardo Bueno wrote:You don't want to use lazy initialized collections? Then just define them as FetchType.EAGER. If you want a better approach, you can use them lazy implementing OpenSessionInView pattern, which will load them once you try to access it in code. I don't know if it can be implemented without hibernate, though.
FetchType.EAGER is fine when loading entities via Session#get(), but its ignored when using HQL or Criteria.
If you dont want lazy collections on entites loaded by Criteria or HQL you have to explicitly JOIN FETCH them.
Eduardo Bueno wrote:You don't want to use lazy initialized collections? Then just define them as FetchType.EAGER. If you want a better approach, you can use them lazy implementing OpenSessionInView pattern, which will load them once you try to access it in code. I don't know if it can be implemented without hibernate, though.
FetchType.EAGER is fine when loading entities via Session#get(), but its ignored when using HQL or Criteria.
If you dont want lazy collections on entites loaded by Criteria or HQL you have to explicitly JOIN FETCH them.
That is not true, the only way objects are not fetched is with plain SQL.
Eduardo Bueno wrote:You don't want to use lazy initialized collections? Then just define them as FetchType.EAGER. If you want a better approach, you can use them lazy implementing OpenSessionInView pattern, which will load them once you try to access it in code. I don't know if it can be implemented without hibernate, though.
FetchType.EAGER is fine when loading entities via Session#get(), but its ignored when using HQL or Criteria.
If you dont want lazy collections on entites loaded by Criteria or HQL you have to explicitly JOIN FETCH them.
That is not true, the only way objects are not fetched is with plain SQL.
When you use FetchType.EAGER with HQL or Criteria the generated SQL does not contain the specified eager fetching. Instead you should use FETCH JOINs to reduce the database statements to 1 SELECT.
That has nothing to do with what you said before. Just because hibernate generates more than one SELECT command doesn't mean the entity will not be fetched.
But maybe I was wrong about EAGER fetching by SELECT.
No matter what, best practices goes around lazy fetching:
Prefer lazy fetching for associations.
Use eager fetching sparingly. Use proxies and lazy collections for most associations to classes that are not
likely to be completely held in the second-level cache. For associations to cached classes, where there is an
a extremely high probability of a cache hit, explicitly disable eager fetching using lazy="false". When an
join fetching is appropriate to a particular use case, use a query with a left join fetch.
Post by:autobot
Can you really tell me that we aren't dealing with suspicious baked goods? And then there is this tiny ad:
a bit of art, as a gift, that will fit in a stocking