Hi, your approaches sound very interesting. I face the problem that I develop my first NH application and therefore I'm not very familiar with best practices of architectural issues. I gave me some keywords which make much sense to me. Do you know any source for a detailed description for MVC- Pattern in conjunction with NH. For example. I face the problem that my Business Objects do not match my mapped classes so the model-part of mvc is a kind of tricky. Refering to your mentioned options I would be also intersted in a smart way of session handling. At the moment I do have Singleton-based SessionManager which opens the session when I start my Win-App and closes it when I close my Application.
Thanks for feedback antoschka On 4 Mrz., 21:41, Stefan Steinegger <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
