It sounds as if the problem may be that you're re-using an entity class for business logic; can you use an interim DTO that's passed to the upper layer? Obviously, the practicality depends upon how the RPC's done and type bindings etc.
Steps 1-4 DB --> [NH] --> Entity --> [your code] --> DTO --> [Consumer] Steps 5-6 [Consumer] --> DTO --> [your code] --> (get entity from DB, apply changes from DTO) --> [NH] --> DB In the worst case scenario, if you can't use a DTO, what about an IInterceptor which overrides FindDirty() for this entity and returns an empty array if it's 'logically clean' for your scenario? /Pete From: [email protected] [mailto:[email protected]] On Behalf Of Sid Shetye Sent: 14 November 2013 02:13 To: [email protected] Subject: [nhusers] Re: Mark entity as Clean despite modifying it's property? Gunnar, Ricardo I did set the "original" values to the "current" values in the hopes that NH will see it as unchanged - but that didn't work. It was done inside the PostLoad Event handler as follows. I had to resort to reflection since it's a private field without an interface... // Get current values object[] currentState = persister.GetPropertyValues(entity, session.EntityMode); // Set original values to current values var fieldInfo = typeof(EntityEntry).GetField("loadedState", BindingFlags.Instance | BindingFlags.NonPublic); if (fieldInfo != null) fieldInfo.SetValue(entityEntry, currentState); Despite doing this, this entity still gets written out when we hit Commit() - so NH might be performing it's clean/dirty decision and enlistment of what must be written prior to this. Gunnar, using the IPreLoadEventListener won't work because the values are NULL at that stage Anne, Appreciate the alternative strategies but they won't work. Our larger design is out of scope here but briefly, 1) Read from database 2) Transform certain properties. Transformation is for compatibility with this next layer of software (that we don't control) 3) Reset entity state to clean so that a Commit() at this point in time doesn't end up creating a dB write. 4) Next layer can do as it pleases with any properties of the entity 5) Reverse transform certain properties 6) If any changes due to #4 or #5 (but NOT #2), issue a write back to dB The issue is that unlike EF, there seems to be no way to perform #3 in NH :( Lastly, I understand there might be an approach via custom User Type. The only downside with custom user type is that we'd be scoped to just that property in the post processing hooks i.e. scoped to property level visibility. Currently our post-processing chain also does additional entity-level processing to the entire entity (all properties) if special "properties of interest" are seen in transit. We'd like to maintain that feature so that NHibernate and EntityFramework databases/projects are on equal footing. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nhusers. For more options, visit https://groups.google.com/groups/opt_out.
