I once wrote this method for resetting the original values:
public static void Reset(this ISession session, Object entity)
{
ISessionImplementor sessionImpl = session.GetSessionImplementation();
IPersistenceContext context = sessionImpl.PersistenceContext;
EntityEntry entry = context.GetEntry(context.Unproxy(entity));
if ((entry == null) || (entry.RequiresDirtyCheck(entity) == false) ||
(entry.ExistsInDatabase == false) || (entry.LoadedState == null))
{
return;
}
IEntityPersister persister = entry.Persister;
Object[] currentState = persister.GetPropertyValues(entity,
sessionImpl.EntityMode);
Object[] loadedState = entry.LoadedState;
for (Int32 i = 0; i < currentState.Length; ++i)
{
loadedState[i] = currentState[i];
}
}
Can you try it?
RP
On Thursday, November 14, 2013 2:12:41 AM UTC, Sid Shetye wrote:
>
> 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.
