As I know, the referenced entities in the bag are only evicted if they are mapped with cascade=all. That's the reason why I stopped using it.
If I where you, I wouldn't use evict and refresh to discard changes. As I understand it, it is not designed to couple it directly to user actions. Evict has this cascading problem, making it very dependant of the mapping and easy to break. Refresh reloads the state that has been stored to the database. This means, if NH already flushed some changes (eg. before a query), changes are not undone. You actually can not determine which changes made within the session are undone. Only that changes made outside of the session are undone for sure. I would do one of these: - When you store: open the session and persist all the changes, commit and close the session. - OR When you start editing open the session and either commit or rollback the changes. - OR deep-copy the data for the editor and either throw away or merge the copy. - OR copy the entities to a model (model-view-controler architecture) and only copy it back when you store (same as above). On Mar 4, 3:45 pm, antoschka <[email protected]> wrote: > OK, after hours of trial & error I have a solution, but do not > understand why it did not work before. > > What happens. > There is UI with bound data. the user enters something leave the edit > field end later decides: > -either to save the data or > -to discard changes > > what I did was: > - before the data was changed I set the bound entity session.Evict > (boundItem) > - in case the user decided to save changes, I tried to merge the bound > Item and then invoked a session Flush ( there the error came up saying > an object with same identifier is already there, although I checked > before session.Contains(bounItem) and it returned as expected "false") > - in case of discarding changes I did session.Refresh(boundItem) > > in fact what I did was to skip the first two steps and now it works - > probably risky is the fact the possibility of an intended flush before > a possible refresh (i work with default FlushMode). > > What's surprising to me is, that I originally thought that my initial > proceeding is the exact use case for evict & merge. > > Working with lazy initilizations of one-to-many bags I do have a guess > and would like to know if this could be the case. Is it possible that > I evicted my boundItem but a proxy of one of my many-to-one bags was > not aware of being proxy of an evicted object. > After Merging the following check for the existence of the object and > found a proxy which corresponds to my bound Item. > > Could that be the case > > Thanks in advance for your feedback > > antoschka > > On 4 Mrz., 14:10, Fabio Maulo <[email protected]> wrote: > > > 2009/3/4 Stefan Steinegger <[email protected]> > > > > var attachedObject = session.Merge(detachedObject); > > > Assert.IsTrue(session.Contains(attachedObject)); > > > > Don't use attachedObject anymore, it is not in the session an must not > > > be referenced by any attached instance. > > > > I don't really understand why you use Detach. You should not use > > > Detach, > > > It depend for what you are using Merge... StaleObjectStateException ? ;) > > -- > > Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
