Acco Lade wrote:
Que? You mean if I have a Organization with a List of Employee, I cannot add a new Employee without loading the entire Employee table?
That's true. Hibernate will need to load the entire collection before adding the new element. Why so? Because it needs to enforce the Java collection semantic. Think about it...
- The collection is a
set: duplicates must be avoided - so when adding a new element, Hibernate needs to know all the others (at least their ID).
- The collection is a
map: keys need to be known for the map to be usable...
- The collection is a
list: the indices must be known...
- The only collection that *may* not require to know anything in advance is the
bag (and I'm not even sure about it) - but this is not a regular java collection type...
Acco Lade wrote:
So, all the one-to-many relationships are esenstially useless unless we are talking about a very small -many instanstances?
Useless? Why so? It will perform correctly in all cases - but with bad performance with very large collections - unless you know what you are doing and use the tool accordingly.
Acco Lade wrote:
I guess the work-around is to add the Employee separately?
The easiest workaround in this case is probably to define the list element as lazy. This way Hibernate won't load their actual content but just a proxy with their IDs... This is quite efficient, believe me ;)
Think about it... Loading the element IDs will be required anyway - whatever is your strategy to update the list, you will at least need this information...