Thank you for taking your time to read and answer this topic. I do not want NH not to save my changes, I want to control the order in which NH saves my object graph, so that I can provide feedback to the user.
Here is a simple test situation. A entity Parent contains a list of entity Child (Children collection). I modify the Parent and some Child, but, because each Child is slow to update, I want to save each Child first, then the Parent. Then I can provide visual feedback to the user, who can see save progress. If I call SaveOrUpdate() then Flush() on the child, The first child is saved, then the parent is flushed and also every child is, in the same flush. I was clearing first the session to avoid the problem, but I need then to reattach my objects, which is pretty awkward. Same thing for evicting objects. Finally in my case, iParent is not a single entity but an object graph and Children are subgraphs of Parent (that is why evicting is not easy to use). NH throws me exceptions because transient entities are referenced in a part of the parent graph (auto flush does an Update not a SaveOrUpdate, and the transient item is a transient entity in an already loaded persistent collection). My business logic does not know about how the save is made, I got a repository for that. Evicting/Clearing session does not make my business logic more unaware of persistence layer, but cascades do. People should be able to disable this feature if they want more control on NH. It should come bundled with NH and not outside of it. Currently this is not a 'default' behaviour, but the only behaviour. Reminder : http://brian.pontarelli.com/2007/04/03/hibernate-pitfalls-part-2/ http://stackoverflow.com/questions/673564/nhibernates-automatic-dirty-checking-update-behaviour-turning-it-off http://fabiomaulo.blogspot.com/2009/03/ensuring-updates-on-flush.html I know I need to write a test case. I'll do when I'll have time and motivation. Thank you very much for taking some time to answer, Stefan. On Aug 13, 4:47 pm, Stefan Steinegger <stefan.steineg...@bluewin.ch> wrote: > Nelson, one of NH's benefits is what is called "persistence > ignorance". It means that the business logic does not need to know > about persistence. It just changes the state of the entities (which > are attached to the session), and these changes get persisted > automatically by NH. The business logic does not have to call anything > to make this happen. > > The "normal" solution for unexpected updates is: if the business logic > does not want to have something changed, it should not change it. > > I know, it is not always that easy. I just try to explain why this is > a reasonable default behavior. > > I'm not really sure why you want to have NH reset some of your > changes. It's actually the business logics responsibility to change > the entities as it should be. > > Btw, to undo changes made outside of the session (detached), use Get > to get a new instance, or Refresh. > > On 13 Aug., 14:47, Fabio Maulo <fabioma...@gmail.com> wrote: > > > 2009/8/13 Nelson <nelson.cab...@gmail.com> > > > > Shall I directly post it to NHibernate's JIRA in addition to that? > > > IT'S A BUG. > > > Which is the JIRA ? > > > -- > > Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to nhusers@googlegroups.com To unsubscribe from this group, send email to nhusers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
