Hibernate version: 2.1.6

Name and version of the database you are using: Postgres

My team and I are trying to decide b/w using hibernate or JDBC/SQL, one question we keep hitting upon, that I don't have an answer for yet, is about updating an object.

Say I have an object A that has a one-to-many relationship with object B...

If using JDBC/SQL and I was adding a new object B to the set that object A has, it would require one SQL statement say "insert into tableB (col1, col2, "objectid of A") values (?,?,?)"....

Now doing this in hibernate would require first having to fetch objectA (that's one SQL select), then access the set of object B's (another select) and then add the new object B to the set and save object A (an SQL insert)

So, is there a better way to do this in hibernate that would elimnate the performance hit of these extra SQL statements?

thanks in advance!

just use load(objectA) to retrieve a proxy and add this to the set.

ok, the load is doing a select, then adding to the set would require getting the entire set in the first place, so that's another select, and then finally adding it to the set and saving objectA is finally doing the insert.

Is this just the way it has to be done or am I overstating the process needed to add a new object to another object using hibernate?

thanks again....

Assuming lazy loading is enabled for all classes, Hibernate does not require any SELECTs for your scenario. Specifically, to get a reference to objectA, you call Session#load(...) in Hibernate. Despite the name of this method, this does NOT hit the database unless you try to access a property of objectA. Now, with a reference to objectA, you can call:

objectB.setA(objectA);
session.save(objectB);

The result of all this is a single INSERT and no SELECTs.

BUT, if there is a bi-directional relation between A and B, then setting the relation "the right way" requires updating both sides of the relation in your code. Example:

objectB.setA(objectA);
objectA.getBs().add(objectB);

This requires at least one SELECT (if you use eager fetching) or two (if you don't). In practice, I don't think all this matters much. Hibernate's caching support is much more than one could typically achieve using straight JDBC, and this offers a lot of performance advantages. My advice would be not to take too narrow a view of the relative performance of each by comparing simple scenarios like this. It provides a skewed picture at best.

Ok, so if I have an objectA with lets say 200 objectBs...
then in order to add a new objectB to the set that objectA has am I correct in assuming that this line: objectA.getBs().add(objectB) gets all 200 objectBs inorder to just add this new one....

From an object-oriented view this makes sense to me, but from efficiency it doesn't seem right. I ask this because we have a distributed app that uses XML over sockets to communicate with the server, so what is sent across to add lets say a new contact to a users address book would be the userid, and all the info for adding the new contact...

hope i'm making sense here...

Thanks again everyone