At least that is what I am seeing.

For example:

Job job = null;
Type type = job.GetType();

//Loading up a job for the UI
job = (Job) session.Get(type, "SomeID");


//User can change TicketNum in UI
job.TicketNum = "NewTicketNum"

//Checking to see if a job already exists with this ticket num
ICriteria crit = session.CreateCriteria(type);
crit.Add(Expression.Eq("TicketNum", "NewTicketNum"));


//At this point when this is called, it saves the TicketNum I just assigned--not desirable
IList list = crit.List();

I cannot use TicketNum as the ID (database replication), but it must be unique to the user on his system. I have specified a unique constraint, but for me to figure out if they have violated the constraint by way of exception, requires me to do something awful like this:

exception.Message.Contains("UNIQUE KEY");

Because there aren't different SQL exceptions.

Essentially any persistent object (which your job is, since you loaded it) may have its state flushed to the database when you do a query to ensure the query results are in a consistent state.

I made a post in the following thread trying to clarify how transparent persistence works and there's some good info there that covers your question - maybe it'll help clear things up for you: http://forum.hibernate.org/viewtopic.php?t=974039

Cheers,

Symon.

Ah yes, very helpful. Changed my FlushMode and that fixed things right up.

Keep in mind that if you change the flush mode you may get back a result set that doesn't include changes you've made between loading an object and flushing it.

For example, say you're going to load a couple of jobs, modify their description to add the keyword "foo" and then execute a query for all jobs that have the keyword "foo" in the description all in a single unit of work. If you don't allow the flush before the query is executed the results that come back from the database will not include the jobs you changed, so they won't appear in the result set.

If you're running in a transaction it's often OK to let the flush happen since if you decide you don't want to commit the unit of work you can roll back the transaction and everything will be undone.

Just worth being aware of.

Cheers,

Symon.

I appreciate the warning. The flush mode I have it set to is "NHibernate.FlushMode.Commit", which seems more natural to me. I am not accustomed to having data sent back to the DB without me explicitly saying so.