Two thoughts here: 1) Long running transactions don't/shouldn't require domain code. Your domain throws an exception, something else catches it and doesn't commit the transaction. You don't have to discard the transaction, just make the user fix it before save.
2) If you REALLY want the "don't save if I don't say so" then evict items right after loading them. Of course then lazy loading etc won't work.... -Will On Mon, Mar 23, 2009 at 9:16 AM, [email protected] <[email protected]> wrote: > > These all involve me putting NH specific code into my domain model, > which I don't want to do. > > I expect it to save if i tell it to, and not if i dont, why is this so > difficult? > > Thanks > > Andrew > > > On Mar 23, 4:08 pm, Will Shaver <[email protected]> wrote: >> You have a couple of options here: >> >> a) evict the item >> b) use long running sessions, and make the user fix the problem before >> committing the transaction. Won't work in an over 18 case, but will >> work for bad formatted email addresses >> c) change the entity back to the way it was prior to the request >> >> hmm.. I'm sure there are others. I'd look into the long running >> sessions. If you're using rhino tools, there's even a way to have >> multiple long running sessions concurrently for the same user. >> >> -Will >> >> On Mon, Mar 23, 2009 at 8:43 AM, [email protected] >> >> <[email protected]> wrote: >> >> > I'll describe my specific situation, but this is also a general >> > question around the subject. >> >> > I'm developing a web application, and I'm using a UnitOfWork to create >> > me a session/tx on begin_request and it flushes/commits on >> > end_request. >> >> > On an edit screen for one of my persisted objects, I get the object >> > from NH, set the properties with the POSTed data from the edit form, >> > then validate the object to make sure no business rules are violated. >> > In pseudo code: >> >> > var person12 = Session.Linq<Person>().Query().Where(x => x.Id = 12); >> >> > person12.Age = int.parse(form["Age"]); >> >> > if(person12.Age >= 18) >> > Session.Update(person12); >> > else >> > throw new ValidationException("You must be at least 18"); >> >> > The problem is that if the validation fails, the person object is >> > still saved when the transaction is committed on end_request. >> >> > What should I do about this? >> >> > It seems very strange to me that dirty objects should get saved >> > without me telling the session to update it. Can I just turn this >> > behaviour off? If so, how? It seems strange that there is a >> > Session.Update(object) method, if you cant turn it off. >> >> > If i cant turn it off, what am I supposed to do? I've had suggestions >> > of Evict()ing the object or calling setReadOnly, but they feel like >> > hacks. I don't want to rollback the transaction, because what if ive >> > got other updates pending that i do want to commit? >> >> > Am I missing some concept which is why automatic dirty object updating >> > feels wrong to me? >> >> > Thanks for any advice, >> >> > Andrew
