|
I'm hoping you'll reconsider this big change in behavior.
In our app, our EntityServerInterceptor looks something like this:
protected override bool ExecuteSave() { //Execute the 'pre-save', 'DefForce/EF save' and 'pre-commit' logic in the same transaction using (var tx = new TranscationScope(...)) { //Get all the entities that are being saved var savedEntities = EntityManager.FindEntities<Entity>(EntityState.AllButDetached).ToList();
//Give all the entities a chance to do things before the save foreach (var e in savedEntities) e.ServerPreSave();
//Perform the actual save var saveSucceeded = base.ExecuteSave();
//If the save failed, exist immediately // (this will also abort the transaction) if (!saveSucceeded) return false;
//Give all the entities a chance to do things after the save foreach (var e in savedEntities) e.ServerPreCommit();
//If we've reached this far, everything must have succeeded tx.Complete();
return true; } } |
In our case, until ExecuteSave returns, we don't consider the save complete. Sure the data has been sent to the database, but until tx.Complete() executes, the data is not permanent. And that ServerPreCommit is the place where our entities want to be able to access the original values. It seems like while you are still in ExecuteSave, it makes sense to think of the entities as 'being in the process of getting saved' instead of 'already finished being saved'.
Just to play a bit of devil's advocate.....by the same logic you describe where old values shouldn't be available 'once the data has been saved into the database' - then shouldn't the entities also have an EntityState of Unchanged since 'the data has been saved into the database'? It seems inconsistent to have an entity that still thinks it is Modified but it doesn't have any original values that are different than the current values? Now to be clear, I am most certainly not suggest that DevForce be changed so entities all go to Unchanged during ExecuteSave(). That would break even more of our existing code and be a nightmare to work around.
Was there some use case that caused this change to be made? I'm confused. If somebody is really writing code in ExecuteSave and they are asking for the original values.....who would ever expect the *original* values to be the newly saved ones? If you are explicitly asking for the original values doesn't it imply that you think the original values are different than the current?
Obviously I feel strongly about this for a couple of reasons - not the least of which is that we have a lot of code that seems perfectly reasonable and reads really well that was just broken by this change. I know we could stash away all the original values ourselves and then just try really hard to not ask DevForce for the original value of properties in this one small part of the lifecycle of an entity - but that takes something that used to be simple and elegant and turns it into something that is awkward and error prone.
|