none
Updating detached Self tracking entities in EF 4...

    Question

  • Hi,

    I've just seen the blog post... http://blogs.msdn.com/b/diego/archive/2010/10/06/self-tracking-entities-applychanges-and-duplicate-entities.aspx and have a question related to that.

    Any help/suggestions would be really appreciated - I've been stuck on this for about 2 days now.

    I have an orderDetails (OD) with a product reference.
    I pull the OD back into the UI (Window1) with one service call that includes the product - as I want to display the product name.
    The user can click on the product and pull up product details where they may edit the product information - this is in another window (window2) - having retrieved the product information in a separate call.
    Close Window2 and send a message with the updated product info to Window1.

    In code I set od1.Product = product i.e the updated product from window2.

    Send changes back to server....
    - create a context.
    - call applychanges on the OD and get the dreaded exception.

    I can simulate this in the following code...
               Product product = null;
                GeneralTestDatabaseEntities ctx1 = new GeneralTestDatabaseEntities();

    // This is the original call to get the order details and related product info - displayed in Window1
                OrderDetail od1 = ctx1.OrderDetails.Include("Product").Where(od => od.ID == 1).FirstOrDefault();
                od1.StartTracking();

    // New call to get the product details and change them...this would happen in window2
                using (var ctx2 = new GeneralTestDatabaseEntities())
                {
                    product = ctx2.Products.Where(p => p.ID == 1).FirstOrDefault();
                    product.StartTracking();
                    product.ProductName += " 1";
                    ctx2.Products.ApplyChanges(product);
                    ctx2.SaveChanges();
                    //product.AcceptChanges();
                }

                // Simulate something happens in the client....i.e. message has gone back to Window1, where the

                //user will update the quantity
                od1.Quantity += 1;
              
                od1.Product = product;   //// (****1)

    // Simulate sending back to client....
                GeneralTestDatabaseEntities ctx3 = new GeneralTestDatabaseEntities();

                ctx3.OrderDetails.ApplyChanges(od1);

                ctx3.SaveChanges()

    If I use method (1) in the article - just resetting the ID at point (****1), that works OK, but I can't then get at the updated product name - i.e. od1.Product.ProductName will still give me the old name. This would be no good for the UI as it would still display the wrong product name.

    This only seems to be a problem when I change the underlying product information.
    If I retrieve a different product and set the od1.Product to the new product then everything works OK.
    If I retrieve a different product, as well as changing it, then I get the same problem back again.

    Please could someone explain what's going on here! thanks. I compare this will the hibernate SaveOrUpdate method which just did as it was told :)

    Another solution I've found is to stoptracking on the product and OD STEs before calling od1.Product - product
    However, this means I have to work out in the client sets of scenarios when to do this and really this should be handled server-side.

    Other ways I've got this to work are by inserting the following just before the ApplyChanges call... attaching the orderDetails and changing the state of the

    orderDetails.

    ctx3.Products.Attach(od1);
    ctx3.ObjectStateManager.ChangeObjectState(od1, EntityState .Modified);

    Any help/suggestions would be really appreciated - as I am confused as to the best approach to take.

    Regards,
    Joseph

    Thursday, January 27, 2011 12:54 PM

All replies

  • Hi,

    Sorry, but I;m giving this one a nudge.

    I'm seeing a lot of posts around this sort of area... non quite hits the mark and it seems to be quite a point of pain.

     

    any guidance would be appreciated.

    Thanks.

    Thursday, January 27, 2011 11:58 PM
  • Hi,

    It's better to copy the values from the updated product to your original product than setting the reference to the update product.

    P1.Name = P2.Name

    P1.Description = P2.Description

    .....

     

    Greetings

    Sunday, January 30, 2011 9:43 PM
  • Hi,

    Thanks for that.

    I need to try that out, but I think that it will mark the product entity as changed.. so on the server-side, EF will try to apply those

    changes, in which case I'll end up applying all the other values that are currently stored against that product in the current window.

    I've seen stuff about turning off change-tracking before setting  od1.Product = product; but it seems like a real pain to have to do this,

    As this is a scenario that could crop up regularly:

    - Open Window1,

    - open linked window2 - make changes in window2 and save them

    - Pass changed entity back to window1 for display

    - Make further changes to window1 and save them

    Does anyone know of a "simple" way to take a set of detached related STEs and apply them without running into these types of issues?

    Thanks

    Monday, January 31, 2011 10:05 PM
  • Hi Joseph,

    Did you encounter a similiar issue of the one in this thread?
    http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/fb40daee-215c-46bf-96c2-ec639141c768

    Would you please try Joe's workaround? 

    Have a nice day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, February 02, 2011 7:47 AM
  • I ran into the same issue

     

    As posted on this thread:

     

    http://social.msdn.microsoft.com/Forums/en-US/adonetefx/thread/24bc0064-dff2-4d54-b75d-2eb2996759b4

    Wednesday, February 02, 2011 8:07 PM
  • Thanks to both of you...

    I've been following/posting on the thread Michael mentioned (http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/fb40daee-215c-46bf-96c2-ec639141c768)

    I've seen the suggestions to stop/start tracking - but that seems to be a pain and I can see us having to do that all over the GUI code - which seems

    messy.

    Wednesday, February 02, 2011 9:11 PM
  •  

    I totally agree that the stop/start tracking work-around is not something you want to do explicit.


    Here are my finding so far, for this setup:

    • Given a one-to-many relationship, for instance Parent (0..1) ------ (*) Child
    • Given the case where a Parent exists in the database with one single Child

    Case 1: Using STE with implicit Foreign Keys ("Include foreign keys in model" disabled):

    1. The Parent (without it's Child) is fetched from the Context and detached (for instance, sent to a client over WCF)
    2. The Child is fetched from the Context and detached
    3. The Child is linked to the Parent: parent.Children.Add(child)
    4. The Parent is saved, using STE's ApplyChanges extension method
      -> Expected: no changes to be saved, nothing has changed
      -> Reality: System.Data.OptimisticConcurrencyException:
                      Store update, insert, or delete statement affected an unexpected number of rows (0).
                      Entities may have been modified or deleted since entities were loaded. Refresh ObjectStateManager entries."

     

    Case 2: Using STE with explicit Foreign Keys ("Include foreign keys in model" enabled)

    • Behavior in step 4. is as expected. No changes to be saved, no Exception.

     

     

    The behavior of STE's should not depend on the including/not including of FKs in the model!
    This is, on our opinion, a STE bug.


    Does Microsoft acknowledges this as a bug?
    Should I provide a simple unit test showing this behavior?



    Thanks for your time,
    Koen

     

     

    Thursday, February 03, 2011 8:57 AM
  • Hi Koen,

    Thanks for your post! 

    I would recommend directly send some feature request or bug report about EF here, https://connect.microsoft.com/dataplatform/content/content.aspx?ContentID=15541.

    BTW, I got some feedbacks from the product team about this issue.  Please see this thread, http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/fb40daee-215c-46bf-96c2-ec639141c768.   Unfortunately, fixing this issue may need to change the whole design of STE, which may not occur in the near future.

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, February 08, 2011 7:53 AM
  • Hi Lingzhi Sun,

     

    Thanks for your reply.

     

    • A bug report has been submitted (https://connect.microsoft.com/data/feedback/details/641859/relinking-detached-self-tracking-entities).
    • Quote from the other post:
         "As product group said, STEs are not designed to handle this type of cases, .."
    

             That's fine, but it should at least be documented what kind of scenarios are supported, and definitely, which ones are not.

     

     

     

    Thanks for your time,
    Koen

     

    Tuesday, February 08, 2011 8:57 AM
  • Thanks Koen! 

    I will try to connect the product team to report this issue as I said in this thread, http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/fb40daee-215c-46bf-96c2-ec639141c768/

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, February 08, 2011 2:21 PM
  • Hi Michael

    wondering if there is some new information about this problem as we face the same sort of problems.

    Regards

    Beat


    Beat Wuethrich
    Friday, November 18, 2011 4:39 PM