You could, I suppose, keep track of an "appended list"

OK, just a note, there is a lot of incorrect stuff written in this thread. :(

The actual functionality is this:

(1) For bags and lists with inverse="true", add() does not initialize the collection

OK, just a note, there is a lot of incorrect stuff written in this thread. :(

The actual functionality is this:

(1) For bags and lists with inverse="true", add() does not initialize the collection
(2) For all other collection mappings add() does immediately initailize the collection

As noted, this behavior is required in order to comply with the contracts defined by the Java Collections API.

It think it is probably worthwhile to include a special Hibernate Persistent Collections that do not necessarily adhere to the Java Collectoins API.

In other words, don't load all the data into memory, let the database worry about duplicate rows, bad foreign keys, and such at commit time.

What says?
Acco

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...



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.




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...

>> When I use a session to load Organization, the Employee list won't load the Employees unless I "touch" it, right?

>> Does Hibenate load Employee proxies still? That would be bad for me because I may have literally millions of Employees.

>> I would like the Employee list to remain EMPTY with no elements whatsover in it until I touch it. Is that possible?

>> Now, I close the session and send the Organization further up the system to the UI, where a new Employee is added to the same Organization object instance. The Employee list should now contain exactly 1 element right? And so, I can proceed to send Organization down again and then persist the new Employee ??? <<

>>It think it is probably worthwhile to include a special Hibernate Persistent Collections that do not necessarily adhere to the Java Collectoins API.<<<

>> I would like the Employee list to remain EMPTY with no elements whatsover in it until I touch it. Is that possible?

>> Now, I close the session and send the Organization further up the system to the UI, where a new Employee is added to the same Organization object instance. The Employee list should now contain exactly 1 element right? And so, I can proceed to send Organization down again and then persist the new Employee ??? <<

>>It think it is probably worthwhile to include a special Hibernate Persistent Collections that do not necessarily adhere to the Java Collectoins API.<<<

Of course.



Depends upon whether it is a one-to-many or a many-to-many. Obviously, for a one-to-many, the behavior you suggest would be absurdly inefficient. For a many-to-many it is the default behavior, which can be overridden by setting outer-join="true" on the <many-to-many> element.




Ummm. Of course.



Negative, this behavior is not supported. The add-w/o-initialize functionalityt is only possible for a collection that is currently connected to an open session. This is a Very Good Thing. Your suggestion would be incredibly evil, since some operations of some collections would be available for uninitialized collections but most would not. I am not going to try and support that kind of confusing, inconsistent functionality!




Negative. That is contrary to the entire philosophy of the project.


If you want non-transparent-persistence, you can incredibly easily use queries instead of collections. Indeed, it is never necessary to use collections anywhere in the domain model. They are always "sugar".

(1) For bags and lists with inverse="true", add() does not initialize the collection
(2) For all other collection mappings add() does immediately initailize the collection

As noted, this behavior is required in order to comply with the contracts defined by the Java Collections API.