Problem with NHibernate and saving - NHibernate doesn't detect changes and uses old values.

Question

When I do this:

Cat x = Session.Load<Cat>(123);
x.Name = "fritz";
Session.Flush();

NHibernate detects the change and UPDATEs the DB. But, when I do this:

Cat x = new Cat();
Session.Save(x);
x.Name = "fritz";
Session.Flush();

I get NULL for name, because that's what was there when I called Session.Save(). Why doesn't NHibernate detect the changes - or better yet, take the values for the INSERT statement at the time of Flush()?

Added: To clarify: The Session.FlushMode is set to None, so there are no automatic flushes until I say so. I'm also using GUID primary keys (with guid.comb generator).

The reason I'm doing this is because I'm using the Session as a "dirtiness" tracker. I'm writing a Windows Forms application and every one of my forms has a separate session which lasts as long as the form does. The session is kept disconnected as much as possible so that I don't run out of ADO.NET connections (it's an MDI application and there's no limit how many forms can be opened). Every form also has an "OK" button and a "Cancel" button. The "OK" button calls Session.Flush() and then closes the form; the "Cancel" button just closes the form and silently discards all changes the user has made.

Well, at least that's what I would like. The above bug is giving me problems.

Answer 1

Unless you have a very good reason not to, you have to use a transaction instead of an explict flush call.

using (var session = createSession())
{
   using (var transaction = session.BeginTransaction())
   {
      Cat x = new Cat();
      session.Save(x);
      x.Name = "fritz";
      try
      {
          transaction.Commit();
      }
      catch
      {
          // prevents your database from getting corrupt when you have a bug
          transaction.RollBack();
          throw;
      }
   }
}

In a real application, it is a good practice to hide the transaction creation, commit and roll-back in a separate part in your application, so that you don't have to call it in each data-access block. In most applications with a relation database, one transaction is wrapped around the whole code that processes one screen for a user. This causes all actions made by the user to succeed, or fail when there is a bug, as an atomic block. All data changed by the user in a screen is stored, or nothing is stored, never parts of it.

Answer 2

NHibernate does track the changes, but your code as written will cause it to issue an insert with the values at the time you called Save and an update for the changes made after calling Save. Save makes the object persistent (insert), then NHibernate begins tracking changes made to the persistent object (update). Both the insert and the update are committed when the session is flushed.

We're facing similar issues with our Windows Forms application and I think we're going to take a different approach. The FlushMode is left at Auto (default) and the object is evicted (ISession.Evict) from the session if the user cancels the operation. Evicting the object makes it transient which is exactly the desired behavior.