Original values on update

[ielbury]

Hi Nick,

This is a nice utility that IMO has many applications.

One of the things that I would find useful is the ability to have access to the original values when updating to make decisions and if the triggers are integrating things like SignalR or Hangfire, be able to better control the integration points.

This is just an idea and I wanted to see how you felt about it.

I realize that I can get the original values as a property bag using:

var originalValues = entry.Context.Entry(entry).OriginalValues;
var originalUpdateTime = originalValues.GetValue<DateTime>("UpdateDateTime");

What if the Entry interface was changed to say:

public interface IEntry<out TTriggerable> where TTriggerable : class, ITriggerable {
        TTriggerable Current { get; }
        TTriggerable Original { get; }
        DbContext Context { get; }
}

I could also see a lazy loaded projection of the Original property bag into a concrete object for the model (TTriggerable) so we would have a strongly typed object for Original.

[NickStrupat]

Hi ielbury,

Thanks for the feedback.

I had been thinking about making this change a couple of months ago. I think it's a pretty good idea. I'll take a crack at building a proxy TTriggerable class at run-time that wraps the original entity's property bag.

I'm actually working on integration with SignalR. I'm building several components which together will provide automatic updates from entity changes to view-model changes in the browser (KnockoutJS view-models to start).

[NickStrupat]

So, the current master branch has a working TTriggerable Original {get;} property which wraps the property bag. I'm just finishing up the refactoring so that only the update and delete (ing/failed/ed) event entries contain this property.

I am thinking this feature might better serve Entity Framework users as a separate project. I can imagine many users would prefer a drop-in extension method which returns a TEntity proxy class, but don't want nor need the rest of this triggers library.

I still like the integration approach you suggested, so what I'm thinking is to have the Entry classes in this library wrap around the statically-typed OriginalValues proxy class in the new, other library. The other library would be a nuget dependency.

What do you think?