Hibernate version:

Mapping documents:

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs:

Name and version of the database you are using:

Debug level Hibernate log excerpt:



Consider the following scenario.

I am dealing with these classes A, B, C

Instances of A contain a collection of B objects and a collection of C objects
I create a new instance of A and persist it to the database. The contained collections of B and C are also persisted and defined wrt via a mapping file.
Somtime later, I'd like to update the instance of A that was persisted to the database with another instance, say newA which contains collections newB, newC which are instances of A,B,C resp.
Here are the questions:

1 . Which is preferable,

a. Load the instance of A from the database, overwrite the member fields of A, B, C and update it in the database - obviously we'd preserve the primaryIds of A, B, C

or :

b. Update the primary Id in newA, the primaryIds of the members of the collection of newB, newC and update newA to the database


2. If I chose option b, is there an easy way to update the primary Ids for the members in newB and newC without iterating through each and comparing with the members in C?

Thanks

It sounds to me that your missing out on the idea of transitive persistence which is fundamental to Hibernate.

Within the scope a session/transaction simply reference an instance of A, make your changes to A,B,C variables etc. Then commit the transaction. Hibernate will automatically dirty check and persist those objects that have changed.

IF you leave the scope of a session then you'll have a detached object A which you'll need to reattach with a call to "saveOrUpate" or simply "update".

You'll only need the calls to saveOrUpdate if you're reattaching. Hibernate will automatically notice if you change the values and references of an object as long as you do so within the scope of a transaction.

You will find much much more info about this in Hibernate in Action as well as the hibernate reference that is included when you download hibernate.

Good luck
Joe

Hi Joe,

I have a somewhat related question. I am using hibernate in a Swing app, where objects may be updated while detached. Often when I reattach these dirty objects using Session.update(), I get Hibernate exceptions saying that a row couldn't be found. In most cases it seems like a delete is attempted that can't be found.

1) Should update() to reattach always work in principle, assuming that there's no bug somewhere?

2) If not 1), what situation could cause a reattach via update() to fail for a detached object?

Thanks,
Thom

Thom,




This makes me think that this doesnt happen frequently. Do you know an full usage scenario that causes this?

The purpose of update is to both reattach an object to a session and more specifically to tell Hibernate to persist this objects latest state. Other methods such as lock() reattach but tell hibernate to make the state of the object match what is in the db and not the other way around.

Anyway, you should check to verify that these items you are calling update on have primary keys according to your id generation strategy. For example, if you're updating and you let hibernate manage ids, then your object should have one. IF, you are just calling update on a bunch of objects and some of them may be transient in the sense that they've never been persisted, then switch over to using "saveOrUpdate". This method with the aid of your unsaved value strategy will update persisted objects or persist transient objects.

Now, if you're are sure these objects should already be in the db and when you go to reattach "update" and you're being told they dont exist, then you might be having an issue with cascading deletes. Meaning, some associated object is getting deleted and its taking this one down with it.

Just some ideas....


Sorry for the lack of clarity or cohesion to the response.

Joe

Hi Joe, thanks for the response.

Well, I confess I haven't yet done the legwork to isolate a simple failure scenario, but the general idea is this:

I have a 'root' object, called a Book, which has many constituent attributes and collections. Since this is a Swing application, it wouldn't make sense to keep a hibernate session open indefinately, so it is closed whenever a transaction is committed.

When a new operation is performed by the client on a Book, that operation may need db access to a lazily instantiated property of book, or it may need to save changes. Therefore the first thing I do when starting such an operation is to open (or clear) a session, and reattach the Book via Session.update(). Even though the session is clean, I sometimes get a HibernateException claiming that a row could not be found during insert/update/delete. A look at debug output suggests that the last attempted db operation was a delete of an an object several layers deep in the constituent object graph.

Of course, I'm 99% percent sure I'm misusing hibernate in some way, leading to this problem, but I'm not quite sure how. I'm assuming that update() should always work, provided the detached object is not transient. I guess I'm not sure how update() could fail, since it is just being told to update the db to match the java object. Somehow it gets confused when updating constituent collections.

Anyway, I don't think anyone could solve this problem without more information on what's being done with the detached object, so I'll post more later if I can narrow down what's happening...

Thom

Thom,

Your latest post makes me feel very confident that you have something incorrect in your mapping files. You indicated that the last object was a delete and that you now get rows not found on an associated object.

As in my last post I think you have a problem with cascading deletes.

Another though, perhaps you deleted a member of the object graph during a session and then didnt delete it from your collection or otherwise. Keep in mind, Hibernate will only make that object transient but it won't remove all references to it that you have in the JVM. So, later you may try an update on an object that no longer exists in the database.

Consider looking through your code for this possibility.


Good luck
Joe