New Posts New Posts RSS Feed: Breaking change to server save lifecycle?
  FAQ FAQ  Forum Search   Calendar   Register Register  Login Login

Breaking change to server save lifecycle?

 Post Reply Post Reply Page  12>
Author
stephenmcd1 View Drop Down
DevForce MVP
DevForce MVP


Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
Post Options Post Options   Quote stephenmcd1 Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
stephenmcd1 View Drop Down
DevForce MVP
DevForce MVP


Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
Post Options Post Options   Quote stephenmcd1 Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
sbelini View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 13-Aug-2010
Location: Oakland
Posts: 786
Post Options Post Options   Quote sbelini Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
stephenmcd1 View Drop Down
DevForce MVP
DevForce MVP


Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
Post Options Post Options   Quote stephenmcd1 Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
sbelini View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 13-Aug-2010
Location: Oakland
Posts: 786
Post Options Post Options   Quote sbelini Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
sbelini View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 13-Aug-2010
Location: Oakland
Posts: 786
Post Options Post Options   Quote sbelini Quote  Post ReplyReply Direct Link To This Post 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
Back to Top
stephenmcd1 View Drop Down
DevForce MVP
DevForce MVP


Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
Post Options Post Options   Quote stephenmcd1 Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391
Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
stephenmcd1 View Drop Down
DevForce MVP
DevForce MVP


Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
Post Options Post Options   Quote stephenmcd1 Quote  Post ReplyReply Direct Link To This Post 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

Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391
Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Posted: 07-Dec-2012 at 5:52pm
:)  That's TBD at the moment.  I'll update you next week.
Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391
Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Posted: 10-Dec-2012 at 5:52pm
It looks like we can do a 6.1.11 release the middle of next week.
Back to Top
stephenmcd1 View Drop Down
DevForce MVP
DevForce MVP


Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
Post Options Post Options   Quote stephenmcd1 Quote  Post ReplyReply Direct Link To This Post 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!

Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391
Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Posted: 18-Dec-2012 at 10:52am
Yes, 6.1.11 will be released tomorrow.
Back to Top
stephenmcd1 View Drop Down
DevForce MVP
DevForce MVP


Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
Post Options Post Options   Quote stephenmcd1 Quote  Post ReplyReply Direct Link To This Post Posted: 18-Dec-2012 at 12:07pm
Great, thanks!
Back to Top
kimj View Drop Down
IdeaBlade
IdeaBlade
Avatar

Joined: 09-May-2007
Posts: 1391
Post Options Post Options   Quote kimj Quote  Post ReplyReply Direct Link To This Post Posted: 19-Dec-2012 at 11:41am
Version 6.1.11 is now available on the download portal.
Back to Top
stephenmcd1 View Drop Down
DevForce MVP
DevForce MVP


Joined: 27-Oct-2009
Location: Los Angeles, CA
Posts: 166
Post Options Post Options   Quote stephenmcd1 Quote  Post ReplyReply Direct Link To This Post 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.
Back to Top
 Post Reply Post Reply Page  12>

Forum Jump Forum Permissions View Drop Down