Hibernate version: 3.2

Hi, I have an object with about 10 or so collections (set), which are mapped with fetch="select" and lazy="true".

Problem: when I use session.get or sesion.load I want to initialize all the collections exactly as if lazy="false" in the mapping, without having to "hardcode" the property names.

My current understanding is:

obj = session.get(someclass)
Hibernate.initialize(obj.getSet1())
- now iterate through the collection and call initialize on each reference)
Hibernate.initialize(obj.getSet2())
- initialize all set 2 objects
Hibernate.initialize(obj.getSet3())
- initiliaze all set 3 objects
Hibernate.initialize(obj.getSet4())
etc

Q. does the above code initialize as per lazy="false"?

If I add a new relationship to the mapping I have to remember to update this code to initialize the new collection - I think I want a method which does all necessary initialization for me dynamically.

Q. does hibernate have a utility which does this?

if not can anyone suggest a dynamic solution...should I be writing my own utility method which reads the mapping and dynamically initializes using java reflection api...or something?

Thanks

Could I get a little more clarification on why you want to use the Hibernate.initialize(obj.getCollection()) as opposed to setting lazy="false" in the XML? Is it that some situations don't need fully initialized collections, while others do?

The reason is that when I do a search (criteria query) I dont need to retrieve all the associations, only when a record is selected do I load all.

Do you think (in this case) I should map my relationships as lazy="false" and use a non-entity pojo for my query results?

How do I build a dynamic query using a non-entity class? - it seems the criteria API only allows entity classes, so that leaves me with HQL and needing to build a query string by hand???

Thanks for your help

Did you find an answer as this is exactly what I need as well. I want all or nothing lazy loading, not one at a time as needed. I am not sure if lazy means the collection is populated one at a time as you iterate through, or if the query loads up the whole collection at once!?

Do you really have to initialize the items in the collection one at a time as well? If you have to do that what is the point in initializing the collection as you can just do it lazily since you are about to iterate over the whole collection!?

Er, yes.


You can access the mapping via sessionFactory.getClassMetadata(YourClass.class) (see also getCollectionMetadata() method). So if you're mapping say Foo.java which owns your numerous collections, retrieve the classMetadata of this class after having loaded the instance of YourClass you want. Then call Hibernate.initialize() by reflection on each collection. I did it recently, it works ok.

You should maybe map your collections using fetch="subselect" so as there's only one select, even if you have many YourClass instances.

1. If your collection is marked lazy=true" then it's my understanding that the collection is lazily initialized. That is, nothing in the collection is initialized until the first element is retrieved from the collection. At that point, everything in the collection is loaded all at once.

2. If you call Hibernate.initialize(), that loads the contents of the entire collection just like if you had lazy="false".

3. I'm not aware of any method to dynamically initialiaze every collection an object has - you could probably write one yourself that uses reflection.

This should work for me. The objects within the collection will have lazy=false. So when the object is loaded into the collection I should not need to further initialize it right ?

Thanks!

Well no that did not exactly work. Some of the objects in the collection also have collections in them. I need the whole graph to be loaded at once.

It would work better if I could just force one of my topmost collection NOT to load while all the others remain with laze=false. Having trouble with that though :(

OK, all fixed once i made sure I had default access constructor and the class was not final...