Forums Register Login

i not wnat to lazy initialization

+Pie Number of slices to send: Send
if i not use lazy initialization false, any other way that gives me this solutions for collections???
+Pie Number of slices to send: Send
Yes, you can set the fetch stategry in queries.
+Pie Number of slices to send: Send
please gives me any idea? How can i set
+Pie Number of slices to send: Send
I'm not sure I understand what you are asking. Are you unsure how to define a fetch strategy in a query?
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
yes i not want to use lazy collection. can i use
this


???
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.

-Cameron McKenzie
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

ben win wrote:

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.
+Pie Number of slices to send: Send
 

Eduardo Bueno wrote:

ben win wrote:

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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
I was refering to this: https://www.hibernate.org/117.html#A13

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.

 
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
https://gardener-gift.com


reply
reply
This thread has been viewed 1669 times.
Similar Threads
Doubt in Effective Java
Lazy Initialization
what is lazy initialization in hibernate
New java singleton pattern implementation
No need for synchronization; there is "Lazy Initialization"
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 18, 2024 21:38:33.