| Author |
Share Topic Topic Search Topic Options
|
stephenmcd1
DevForce MVP
Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
|
Post Options
Quote Reply
Topic: Breaking change to server save lifecycle? Posted: 20-Nov-2012 at 10:04am |
We just upgraded from 6.1.7.1 to 6.1.9.0 and noticed a change in the behavior of EntityServerSaveIntercptor.ExecuteSave. We have our own custom class that inherits from EntityServerSaveInterceptor. One of the things it does is override ExecuteSave to do certain logic before the save and certain other logic after the save. In 6.1.7.1, we used to be able to look at the 'Original Values' for properties using code such as e.g. myEntity.EntityAspect.GetValue("SomeProperty", EntityVersion.Original). This code still works before we call base.ExecuteSave() but now when we do that after base.ExecuteSave(), the 'original' value ends up returning the new value that is being saved. This is breaking a lot of our logic that relied on the previous behavior. What is strange is that the entities still appear as "Added" or "Modified" entity state after calling base.ExecuteSave()....so it isn't like the entire entity thinks it has been saved. Just the original values have disappeared.
I dug a little bit into this and it looks like there was a change to EdmSaveExecutor.HandleModified(...). When I compare that method to the version in 6.1.7.1, there is an extra line that says "entity.EntityAspect.OriginalValuesMap = null". I'm guessing that is what is causing the original values to disappear. I'm not sure if there are also other changes that were made since 6.1.7.1 that contribute to this breaking change and I'm also not sure if this happened as part of 6.1.8 or 6.1.9 (since we skipped 6.1.8).
But most importantly, is this a bug? If not, is there some way to work around this changed behavior? We have lots of code that depends on this so we would like to avoid having to make big changes. Also, we didn't see any mention of this in the release notes. We just happened to notice this breakage while debugging a different issue....otherwise, who knows when we would have found it.
Thanks
|
 |
stephenmcd1
DevForce MVP
Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
|
Post Options
Quote Reply
Posted: 28-Nov-2012 at 5:34pm |
|
Any updates on this? This is a major problem for us causing lots of bad bugs in our app.
|
 |
sbelini
IdeaBlade
Joined: 13-Aug-2010
Location: Oakland
Posts: 786
|
Post Options
Quote Reply
Posted: 28-Nov-2012 at 6:11pm |
|
Hi Stephen,
Sorry for the delayed response. I'm checking with a senior engineer to ensure if this was intended or not.
sbelini.
|
 |
stephenmcd1
DevForce MVP
Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
|
Post Options
Quote Reply
Posted: 05-Dec-2012 at 9:55am |
|
Any update? This issue is critical for us and we are really, really hoping a fix for it can make it in to 6.1.10.
|
 |
sbelini
IdeaBlade
Joined: 13-Aug-2010
Location: Oakland
Posts: 786
|
Post Options
Quote Reply
Posted: 05-Dec-2012 at 11:55am |
|
Hi Stephen,
We are still researching on this.
However, I can tell you in advance that no change in this regard will be present in DevForce 6.1.10.
Kind regards,
sbelini.
|
 |
sbelini
IdeaBlade
Joined: 13-Aug-2010
Location: Oakland
Posts: 786
|
Post Options
Quote Reply
Posted: 06-Dec-2012 at 1:04pm |
|
Hi Stephen,
After researching this issue, we decided that this is the expected behavior. We apologize for not stating it in the Release Notes back when the change was made.
The reason for such decision is that once the data has been saved into the database, one should not expect any "old data" (i.e. original values).
I'm not sure of your use case for seeking older values, but you could always store them before calling base.ExecuteSave and retrieving them later on in the interceptor.
Regards,
Silvio.
Edited by sbelini - 06-Dec-2012 at 1:05pm
|
 |
stephenmcd1
DevForce MVP
Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
|
Post Options
Quote Reply
Posted: 06-Dec-2012 at 4:09pm |
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.
|
 |
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
Posted: 07-Dec-2012 at 4:04pm |
Hi Stephen, As with several other issues you've encountered, this one has caused some internal debate on the "right" approach. The change which caused this new behavior was made in the 6.1.9 release and was a side effect, as we now discard original values after the save to the database so that they are not returned to the client. We released 6.1.10 several days ago and did not address this problem. We've opened a bug report, and will fix this issue in the next release.
|
 |
stephenmcd1
DevForce MVP
Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
|
Post Options
Quote Reply
Posted: 07-Dec-2012 at 5:08pm |
That is great news. We are very happy to hear that. And yes, I'm aware that some of the things I've brought up aren't always black and white. We do appreciate IdeaBlade's openness to customer feedback.
So then my question becomes.....do you have an estimate as to when 6.1.11 will be released? Thanks, Stephen
|
 |
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
Posted: 07-Dec-2012 at 5:52pm |
|
:) That's TBD at the moment. I'll update you next week.
|
 |
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
Posted: 10-Dec-2012 at 5:52pm |
|
It looks like we can do a 6.1.11 release the middle of next week.
|
 |
stephenmcd1
DevForce MVP
Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
|
Post Options
Quote Reply
Posted: 18-Dec-2012 at 10:45am |
Sorry to keep bothering, but is there any update on when 6.1.11 might come out? We are coming up to a code freeze for our application and I'm trying to plan whether 6.1.11 will come in time.
Thanks!
|
 |
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
Posted: 18-Dec-2012 at 10:52am |
|
Yes, 6.1.11 will be released tomorrow.
|
 |
stephenmcd1
DevForce MVP
Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
|
Post Options
Quote Reply
Posted: 18-Dec-2012 at 12:07pm |
|
Great, thanks!
|
 |
kimj
IdeaBlade
Joined: 09-May-2007
Posts: 1391
|
Post Options
Quote Reply
Posted: 19-Dec-2012 at 11:41am |
|
Version 6.1.11 is now available on the download portal.
|
 |
stephenmcd1
DevForce MVP
Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
|
Post Options
Quote Reply
Posted: 28-Dec-2012 at 3:52pm |
|
I'm very happy to report that my issues with the original values have been fixed in 6.1.11. Thanks very much. This saved us from having to make a lot of changes to our codebase.
|
 |