Question about Flushing, ISession.IsDirty and need for a commit

[Patrick Flahan]

Hello,

We are using NHibernate within a WPF desktop application and would like to implement a feature for tracking whether a save is required prior to exiting a screen. Before building something custom, we decided to see if we could use ISession.IsDirty to detect when a save is required. We found that it seems to work for most situations, but if a flush occurs, it looks like IsDirty is set back to false. The changes have been written to the database but not committed, so I think we would need to be able to detect this condition. 

Timing for what we are seeing:

1. Start new session (IsDirty = false)

2. Query object of type Foo (IsDirty = false)

3. Modify foo instance (IsDirty = true)

4. Execute query for objects of type Foo (this flushes)

5. Check session.IsDirty and it is now false.

Other than ISession.IsDirty, is there another way from within NHibernate to detect that even though the session state and database are in sync, we still have changes to be committed? We have looked at listeners and events, but aren't 100% sure about that approach. 

Any suggestions or guidance on this would be greatly appreciated. Thank you,

Pat

[Frédéric Delaporte]

Hi,

So, I guess somewhere between 1 and 3, your application start a transaction on the session. And then somewhere around 5 you wish to decide whether to commit or rollback the transaction?

I do not know of a native way to check whether the session had flushed some changes at some point. You may use an interceptor to keep track of flushes. If you do not mind having your query at 4 (and other queries) running on stale data, you may also disable auto-flush by setting the session FlushMode to Commit.

But I would say, do not bother and just always commit the session transaction, excepted in case of errors. It is not an usual practice to rollback a transaction just because it has changed nothing to the data. A commit will do the job perfectly fine. Otherwise may you explain a bit more your need?

Moreover calling IsDirty is an expensive operation, as expensive as a flush: NHibernate will go through all entities loaded by the session and will compare their current state with the state they were having at load time. Then flushing will do the same again.

Frédéric

[Patrick Flahan]

Hi  Frédéric, 

Thank you for your reply and your assistance.

In the application, the transaction is started between steps 1 and 2. With respect to committing every time, due to a business requirement, we are required to prompt the user to make sure they want their changes saved. Also, the requirements are that they should only be prompted to save, if there are changes. If they decide they don't want the changes saved, we have to be able to rollback.

I think your suggestion of using the interceptor should work perfectly for what we need to do.  It would also free us from having to do the expensive check of IsDirty and the implementation should be relatively simple.

Thank you again for your help.  

Pat

[Paulo Quicoli]

Hi,

If you are using WPF, I believe you have a view model and model classes there. This check for changes IMHO is part of your business layer and not your database layer.

I personally would implement that in my models. If you use Prism you could make use of SetProperty in you model properties to set an application state and so you read this state whenever you want.

All the best

--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nhusers+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nhusers/f96d22aa-98c3-46fb-9021-ab0e4dfbec3fn%40googlegroups.com.