unhaddins has an implementation of IEditableObject for your entities using Castle. Maybe that's what you're looking for.
Diego On Tue, May 4, 2010 at 17:43, tz <[email protected]>wrote: > I'm not asking myself that question.... obviously nH still has > releases scheduled, so there must be missing functionality. > > Sure, > > Architecture: > - A Winforms; one tier application; layered architecture, based on DDD > principles > - Session management is one-to-one with UoW. In fact, UoW is simply a > wrapper around nH Session. UoW is per use-case basis > > Use-case: > - A typical use-case consists of a list panel and a details panel, > both displayed on the same window; they both share the same UoW; > - A use-case starts with displaying a list of entities (in DDD terms: > only the aggregate-root entities); > - The user can choose to modify one of the entities by loading its > details into the screen; > - After having modified something in the aggregate, the user can > decide to discard the change or commit the change made to the > aggregate; > > Decisions: > - UoW is used for change tracking. I don't want to do my own dirty > checking myself, as nH does a better job. > - UoW is used as a "business transaction" principle, the way described > by Martin Fowler. Meaning that the UoW needs to know about "any" > proposed change. I don't even want to do any change queueing > management, as again nH does a better job. > - I continue using the same UoW for the lifetime of the "entities > list". Sometimes, this is equal to application-lifetime. I'm not > concerned with my UoW becoming a giant collection, as the user's data > scope-set is limited. > - When the user discards the applied modifications, I don't want to > evict the aggregate-roots and reload them; I don't want a new > instance, I want the current instance being reverted to an initial > state. Reason being is that 1) I think that's much cleaner; 2) that's > how nH does it with the Refresh(...) already; 3) I don't need to > reload all my lists from the UoW in order to guarantee that all my > instances are actually attached to the UoW I'm using. > - > > On May 4, 8:47 pm, Fabio Maulo <[email protected]> wrote: > > by side, the other thought would be: why within ~6 years of NH and ~9 of > > Hibernate with hundred of thousand applications using both frameworks, > > nobody needs a such feature ? > > > > That is only my thought each time I'm thinking about a new feature in NH. > > > > About revert: > > Which kind of application are you implementing ? > > WinForms, WebForms, WPF, MVC, WCF ? (for sure no REST) > > How you are managing the session ? > > Why you are changing the state of an entity inside the session if the > > modification was not confirmed by user ? > > and so on.... > > > > On Tue, May 4, 2010 at 4:35 PM, tz <[email protected] > >wrote: > > > > > > > > > Interesting question, and the answer is; yes, I have though about it > > > very well, and my conclusion is still that there are soo many similar > > > features in (n)Hibernate to what I want, that with a little bit of > > > help from an insider with more "architectural knowledge of > > > (n)Hibernate", this feature should be small in code. "small" when you > > > know the inside of the product... > > > > > On May 4, 8:18 pm, Carlos cubas <[email protected]> wrote: > > > > tz, have you considered that, maybe just maybe, you are swimming in > the > > > wrong direction? by yourself? > > > > > > -Carlos > > > > > > Practice makes perfect, but if no one is perfect, why practice? > > > > > > > Date: Tue, 4 May 2010 11:49:35 -0700 > > > > > Subject: [nhusers] Re: Refresh from second level cache > > > > > From: [email protected] > > > > > To: [email protected] > > > > > > > "Revert changes with the state of my first load" is what the user > > > > > thinks when she has changed an entity, but regrets. Thus wants to > > > > > cancel. However, she doesn't want to be punished by another > database > > > > > hit. I'm sure many other people decide in this case to start a new > > > > > session or evict the object graph and get it again. All to me sound > > > > > like a half-baked solution for reasons I've mentioned before. > Another > > > > > half-baked solution is to say that you only change the entities > once > > > > > you're 100% sure (no, I want to "commit" once I'm 100% sure). > > > > > > > Having said all this, what I want to reach here, completely fits in > > > > > how I want my application to work. I think it is compatible with > UoW > > > > > and all those other fancy design patterns. This is clearly a > missing > > > > > feature to me. Therefore, I was really hoping for a technical > > > > > satisfying answer, rather than advocating that I'm doing is > something > > > > > which is not written in one of the tutorials. > > > > > > > So, please... does anyone know how I could do this trick of > reverting > > > > > changes in a graph? > > > > > > > On May 4, 7:32 pm, Fabio Maulo <[email protected]> wrote: > > > > > > There is something saying me that your problem is in another > place. > > > > > > "Revert changes with the state of my first load"..... mmmmm > > > > > > > > On Tue, May 4, 2010 at 3:05 PM, tz < > > > [email protected]>wrote: > > > > > > > > > Thanks for confirming that. I silently started guessing that > the > > > > > > > Refresh method shouldn't be what I should use. I started > writing my > > > > > > > own "RevertChanges" on a graph, but I'm stuck on how to evict > > > > > > > collections (plus the attached pending deletes/adds). See my > code > > > > > > > below: > > > > > > > > > public static class ISessionExtensions > > > > > > > { > > > > > > > public static void RevertChanges(this ISession session, > > > object > > > > > > > obj) > > > > > > > { > > > > > > > var source = session as IEventSource; > > > > > > > var action = new RevertChangesCascadingAction(); > > > > > > > > > action.RevertChanges(source, obj); > > > > > > > } > > > > > > > > > private class RevertChangesCascadingAction : > CascadingAction > > > > > > > { > > > > > > > public override void Cascade(IEventSource session, > > > object > > > > > > > child, string entityName, object anything, bool > > > > > > > isCascadeDeleteEnabled) > > > > > > > { > > > > > > > DoRevert(session, child); > > > > > > > } > > > > > > > public override IEnumerable > > > > > > > GetCascadableChildrenIterator(IEventSource session, > CollectionType > > > > > > > collectionType, object collection) > > > > > > > { > > > > > > > var coll = collection as > > > > > > > NHibernate.Collection.IPersistentCollection; > > > > > > > var collectionEntry = > > > > > > > session.PersistenceContext.GetCollectionEntry(coll); > > > > > > > > > // TODO: HELP!!! > > > > > > > //session.Evict(collection); > > > > > > > //collectionEntry.LoadedPersister.Recreate(coll, > > > > > > > collectionEntry.LoadedKey, session); > > > > > > > > > // evicts don't cascade to uninitialized > collections > > > > > > > return GetLoadedElementsIterator(session, > > > > > > > collectionType, collection); > > > > > > > } > > > > > > > public override bool DeleteOrphans > > > > > > > { > > > > > > > get { return false; } > > > > > > > } > > > > > > > public override bool PerformOnLazyProperty > > > > > > > { > > > > > > > get { return false; } > > > > > > > } > > > > > > > > > protected void DoRevert(IEventSource session, object > > > obj) > > > > > > > { > > > > > > > EntityEntry entityEntry = > GetEntityEntry(session, > > > > > > > obj); > > > > > > > > > IEntityPersister persister = > entityEntry.Persister; > > > > > > > EntityMode mode = persister.GuessEntityMode(obj) > ?? > > > > > > > EntityMode.Poco; > > > > > > > persister.SetPropertyValues(obj, > > > > > > > entityEntry.LoadedState, mode); > > > > > > > } > > > > > > > > > protected EntityEntry GetEntityEntry(IEventSource > > > session, > > > > > > > object obj) > > > > > > > { > > > > > > > IPersistenceContext context = > > > > > > > session.PersistenceContext; > > > > > > > > > if (obj is ValueType) > > > > > > > return null; > > > > > > > > > if (context.IsEntryFor(obj) == false) > > > > > > > return null; > > > > > > > > > EntityEntry entityEntry = context.GetEntry(obj); > > > > > > > return entityEntry; > > > > > > > } > > > > > > > > > public void RevertChanges(IEventSource session, > object > > > > > > > obj) > > > > > > > { > > > > > > > EntityEntry entityEntry = > GetEntityEntry(session, > > > > > > > obj); > > > > > > > > > DoRevert(session, obj); > > > > > > > > > > session.PersistenceContext.IncrementCascadeLevel(); > > > > > > > try > > > > > > > { > > > > > > > new Cascade(this, CascadePoint.AfterUpdate, > > > > > > > session).CascadeOn(entityEntry.Persister, obj); > > > > > > > } > > > > > > > finally > > > > > > > { > > > > > > > > > session.PersistenceContext.DecrementCascadeLevel(); > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > } > > > > > > > > > On Apr 30, 7:55 pm, Jason Dentler <[email protected]> > wrote: > > > > > > > > Confirmed it with Fabio: "Refresh is an explicit hit to DB" > > > > > > > > > > On Fri, Apr 30, 2010 at 8:35 AM, tz < > > > > > > > [email protected]>wrote: > > > > > > > > > > > * Transaction over a read didn't help (see reply on Jason > > > Dentler) > > > > > > > > > * Second level cache is for sharing data across > transactions > > > > > > > > > > > On Apr 30, 12:24 pm, John Davidson <[email protected]> > > > wrote: > > > > > > > > > > It does not matter what the UoW pattern says about data > read. > > > You > > > > > > > > > _REALLY_ > > > > > > > > > > need to put a read action in a NHibernate transaction if > you > > > want to > > > > > > > > > improve > > > > > > > > > > performance. Not having your reads in a transaction may > be > > > why you > > > > > > > need a > > > > > > > > > > second level cache (to compensate for not following the > > > specified > > > > > > > rules). > > > > > > > > > > Most of the transactional databases now wrap a read > action in > > > an ACID > > > > > > > > > > transaction on their own, if the request is not already > in a > > > > > > > transaction > > > > > > > > > - > > > > > > > > > > this activity by the database takes more time and > resource > > > than if it > > > > > > > is > > > > > > > > > > done in the application with NHibernate and UoW. > > > > > > > > > > > > John Davidson > > > > > > > > > > > > On Fri, Apr 30, 2010 at 7:14 AM, tz < > > > > > > > > > [email protected]>wrote: > > > > > > > > > > > > > Thanks for the reply. See my comments inline > > > > > > > > > > > > > On Apr 29, 8:26 pm, Jason Meckley < > [email protected]> > > > wrote: > > > > > > > > > > > > I would approach the problem in a completely > different > > > manner. > > > > > > > > > > > > 1. no long running sessions > > > > > > > > > > > > 2. only use 2nd level cache in edge cases as a last > > > resort > > > > > > > > > > > > 3. for multi-step operations/commands I would use an > > > intermediate > > > > > > > DTO > > > > > > > > > > > > to store updates. When the user clicks "save" is when > i > > > would > > > > > > > alter > > > > > > > > > > > > the domain objects. this makes undoing changes much > > > easier. > > > > > > > simply > > > > > > > > > > > > abandon the DTO. > > > > > > > > > > > > > I'm not sure whether you do understand my question, but > I > > > can't > > > > > > > relate > > > > > > > > > > > any of your reply to my question. I also don't agree > with > > > what > > > > > > > you're > > > > > > > > > > > saying... > > > > > > > > > > > * I don't know what "no long running sessions" would > solve > > > for my > > > > > > > > > > > issue. All these things you're proposing are a "very > > > complex" way > > > > > > > to > > > > > > > > > > > do Evict/Load on the same session. > > > > > > > > > > > * 2nd level cache is for performance reasons. The issue > I'm > > > posting > > > > > > > > > > > about is also for performance reasons. So, this cache > > > > ... > > > > read more ยป- Hide quoted text - > > > > - Show quoted text - > > -- > 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]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > > -- 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.
