This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi! Trying to figure a way of using LS 3 feature of entity change tracking for the purpose of change auditing. Currently I don't see a nice way of making a general solution (meaning, one method serves all) for this. Unit of Works in our code are wrapped and also SaveChanges() is wrapped, but the problem is at SaveChanges() I don't see currently a way of knowing which changes are waiting update. I have no access to UoW internal IdentityMap, or some kind of PendingChanges structure. Possibly could be caching entities into our own special structures for this. Or possibly extending Entity class (and make a new base class for all entites) with making OnSaving override and handle audit change there. I know JD also mentioned entity change tracking in context of possible use for auditing purposes. It would be nice to hear what was your idea, how it should be used in that sense? The question is perhaps connected also with the other topic - knowing which entity caused optimistic concurrency exception (also there is a possible situation of knowing what were the pending changes): Thanks for your time. |
|
|
Hi Marko, Thanks for your feedback on how you'd like to undertake entity change tracking (scoping at the UoW rather than just on an entity so that you can effectively get everything you want in one go). When I undertook the initial development of the change tracking I started looking at undertaking it from the UoW level however it became rather messy for managing entity state from the UoW and felt dirty so moved to the tracker per entity which does feel tidier. The enhancement that would likely bring this full circle to solve the challenges you're wanting to handle in terms of auditing would be some mechanism to see the entities currently associated with a UoW. I can't promise anything but I'll have a discussion with the team about how we could do this nicely and evaluate if we could get something in with LS3 to support that. One thing we're actively wary of is how large the UoW class is getting both from a public API level and internally so we try to ensure we only add to it if we absolutely should. Thanks again for your feedback - expect an update within 24 hours :-) John-Daniel Trask |
|
|
Hi Marko, As an update, I'm going to work on adding a way of iterating all the entities tracked by a UoW so that you can scream through them and test them for changes. Following up on your other thread, Ivan suggested a better approach to changing how optimistic concurrency exceptions are fired (as mentioned, it's just going to be really complex to do that). We're still discussing how we might solve this issue with a method that allows you to validate that an entity is not going to cause a concurrency error. I'll look to try and get the UoW scanning for entities done for the next drop of the LS3 beta :-) John-Daniel Trask |
|
|
Hi JD. That's great! Will be looking for your update. BTW, was thinking about this feature a bit more and had a thought about how to make it "complete" (so to say). Currently we can enable entity change tracking only per entity, so for the feature we're discussing, it will be difficult to enable change tracking from one place (and control these auditing features from one place).
|
|
|
Hi Marko, Thanks for your additional thoughts - they're much appreciated so keep them coming! :-) We'll look at the optimistic concurrency changes next week as we keep coming up with new ideas (and your ideas help shape some of the solutions). For the time being I've added the ability to get all the entities associated with a current unit of work. Audit Entities The latest drop of LightSpeed 3.0 adds IEnumerable<T> support to the UnitOfWork (including anything that implements IUnitOfWork now). Now you can read through all the entities attached to a unit of work by executing code like: foreach(Entity entity in MyUnitOfWork) I have not updated the the MyAccount page to state the changes yet but the download has been updated: http://www.mindscape.co.nz/store/myaccount.aspx I hope that helps, John-Daniel Trask |
|
|
Hi JD, Finally had some time to implement this completely. Your new enumerable enabled us to implement Audit feature and it works nicely. As I mentioned already, only thing still a bit rough is the difficulty to enable change tracking from one place (i.e. when creating UoW in factory class), but rather only foreach entity and only after it is loaded. We thought we have all cases covered, but for some scenarios to enable change tracking we just can't do in one place. Still thinking about that idea mentioned above on UoW - something like "EnableChangeTrackingOnEntityModification". Any new ideas from your side? I have some situations about using this new Enumerable for resolving Optimistic Concurrency Exception, but I will switch for that to the other thread. |
|
|
Hi guys, Are there any new moments on your side regarding this enabling tracking of entities on UoW scope? We have auditing now working nicely with the new features from this thread, but to make it complete we're missing the feature of enabling change tracking from one place (i.e. in UoW factory class), as the current mode with change tracking enable only on entity and after it has been fetched (which practicaly means every method working with UoWs must have separate code to enable change tracking). |
|
|
Thank you for the feedback Marko, I will add it to the backlog and will update this thread once we have added support for this. We had discussed adding this type of support during the development of LS3 but ended up without it to see what feedback we got. Would you want to see globally enabling it for all entity types or simply enabling of given entity types? Appreciate your feedback, John-Daniel Trask |
|
|
Hi JD, Our situation is that more than 95% of entity types should be tracked, so a global enable is I guess a more convenient solution (not sure how would selecting entity types for tracking be implemented, sounds like possibly having to update each entity type in already existing models). BTW, until you do implement this, I am thinking about modifying LS designer template for Entity, and creating a small method hooked on PropertyChanged event (in Entity constructor), which would enable tracking. Or alternatively use EntityStateChanged event. But I am not sure at this point, will does events fire only after (initial) change has already happened, or before. Thanks Marko |
|
|
Check out the Entity.AfterLoad method. You can override this to perform post-loading setup tasks. As far as I know (not tested), there should be no problem turning on change tracking in AfterLoad. You could do this via a designer template change or via a common base class (to save forking the templates). If you prefer the PropertyChanged strategy, that could also be implemented in a common base class by overriding OnPropertyChanged. But property and state change events are raised only *after* the change has happened so this is a bit late to be turning on change tracking. |
|
|
Thanks Ivan, Was thinking about PropertyChanged cause I remember JD saying that Entity change tracking is a resource hog. So tried to enable it only when an entity actually starts to be changed. But, you're right, *after* is too late. I will try with AfterLoad. Thanks again |
|
|
I think finally we found a good temporary solution (as I said, scared that ChangeTracking is resource hog, so AfterLoad we concluded is a bit "too early"). We modified Designer Template for FieldProperties and made all setter on properties enable change tracking (if it is not already enabled). This we guess (in theory and in small working example) should give us best of both ideas - enable change tracking as late as possible, but not too late. |
|