Hi,

I have a complex object model, working with NHibernate such that when I call Save or Update on the root/parent object the entire model saves.

Rather than save any changes to the object on the next pass. In certain circumstances I need to save the same object as a new object - therefore insert rather than update, with the minor modifications. The business rules enforce this.

How can I do this. If I go through each object in the object model from the root setting the Id's (luckily every table has an identity!) to the unsaved-value NHibernate doesn't like it. How can I do this most efficiently?

Cheers

is cloning the only solution?

When I call session.flush()

Nhibernate tries to update the original object with new values giving me problems I am sure this is because simply restting the Id still uses the same object which NHibernate is tracking. A clone would produce a new object, therefore would not affect the object NHibernate is tracking.

No, it's not the only solution, but it certainly is the best solution. In my view using something besides a new object is using NHibernate in a way it really isn't intended. The goal is to provide a synchronization mechanism between your object graph and a database.

Think of the problem as if the database wasn't there. Really NHibernate just extends your memory to include far more space. Imagine that all objects are in memory and there is no database. How would you solve the problem you are describing? You are describing having two different objects with the same value, and that is exactly what you should do. Keep in mind that the Ids aren't really needed for memory, that's what references are for. However, they are needed once the object is persisted to the database.

The other option of course is to use a new session. If you remove the Id, and then say you are saving the object NHibernate can treat it as if it is a new object. But I wouldn't recommend following this practice.

I agree with jchapman here. Changing the IDs on an entity that NHibernate already considers persistent and trying to get it to insert a new database row is not only confusing to NHibernate but a confusing hack from an OO perspective. It's not worth the assumed performance benefit from avoiding the creation of a new object instance in memory.

It's easier to see what the "right thing to do" is, and also easier to see how you should think about NHibernate (and OO programming) works if you forget about the database like jchapman said, and consider NHibernate's persistence being to some abstract place such as "deeper in memory" that simply sticks around for a long time.