Print Page | Close Window

Breaking change to server save lifecycle?

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=3813
Printed Date: 13-May-2026 at 12:56am


Topic: Breaking change to server save lifecycle?
Posted By: stephenmcd1
Subject: Breaking change to server save lifecycle?
Date 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



Replies:
Posted By: stephenmcd1
Date 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.


Posted By: sbelini
Date 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.


Posted By: stephenmcd1
Date 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.


Posted By: sbelini
Date 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.


Posted By: sbelini
Date 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.


Posted By: stephenmcd1
Date 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.


Posted By: kimj
Date 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.


Posted By: stephenmcd1
Date 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



Posted By: kimj
Date Posted: 07-Dec-2012 at 5:52pm
:)  That's TBD at the moment.  I'll update you next week.


Posted By: kimj
Date Posted: 10-Dec-2012 at 5:52pm
It looks like we can do a 6.1.11 release the middle of next week.


Posted By: stephenmcd1
Date 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!



Posted By: kimj
Date Posted: 18-Dec-2012 at 10:52am
Yes, 6.1.11 will be released tomorrow.


Posted By: stephenmcd1
Date Posted: 18-Dec-2012 at 12:07pm
Great, thanks!


Posted By: kimj
Date Posted: 19-Dec-2012 at 11:41am
Version 6.1.11 is now available on the download portal.


Posted By: stephenmcd1
Date 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.


Posted By: kimj
Date Posted: 28-Dec-2012 at 4:47pm
And we're very happy to see your report!



Print Page | Close Window