Issues Fixed
The cause of the bug is that EntityFramework resets the EntityState to UnChanged after writing the object to the database. This means that I cannot tell which operation was performed on the entity unless I memoize the state before the operation. The effect of this change is that I can no longer get the EntityState of the item before the operation from the DbEntityEntry.
Breaking Changes
If you are inheriting from TypeInterceptor or ChangeInterceptor the signature of OnBefore and OnAfter has changed.
The new signatures are
protected override void OnBefore(DbEntityEntry item, EntityState state) protected override void OnAfter(DbEntityEntry item, EntityState state)
Hi Chris, I’ve just installed the latest version of Isg.EntityFramework and works quite well. The question I have though: How do I automatically filter all of the IsDeleted=1 in my datacontext? Can I do this easily with your package?
Entity Framework does not really provide an easy way to intercept a query and add additional constraints. I’d love to provide query interception as a feature, but short of writing a whole new LINQ provider, I’m not sure how to accomplish it. You can achieve partial success by using a Generic Repository pattern on top of the DbContext. IRepository.Find can expose an IQueryable that does the automatic filtering for you. This is great when you’re querying on the root object, but would not have the side-effect of filtering soft-deleted records in the navigation properties.
If the primary problem you’re trying to solve is to reduce repetitive where clauses in your code, you could move toward a Specification pattern for applying your predicates. A LINQ-style library for specifications is provided in Isg.Specification.
I’m afraid this is the best I can offer at this time. Good luck!
Is there anyway to get access to the context from a class that inherits ChangeInterceptor?
It appears that an InterceptionContext is created and passed into the TypeInterceptor’s Before and After methods which contains the DbContextBase but these methods can’t be inherited and the context isn’t stored to a field or property
I am trying to implement auditing but to a separate audit table which requires me to be able to add objects to the context
That is a great idea. It will be a breaking change to pass the interception context on through to ChangeInterceptor, but I see that it should be done. Great catch! I’ve created an issue on bitbucket and will work on this soon. Thanks again for the great idea.
https://bitbucket.org/crmckenzie/isg.entityframework/issue/4/interceptors-esp-changeinterceptor-should
Cool – I’m glad you like the idea, thanks for replying and for agreeing to add this in the future.
It is very much appreciated.
0.8.0 has been released. The old methods are still there, but they are deprecated. The new methods receive the InterceptionContext which in turn gives you access to the DbContext. 🙂