locked
Updating Disconnected Entity With Children: Set State vs Second Retrieve RRS feed

  • Question

  • My understanding of updating an entity (with list of children) that is disconnected (such as in an n-tier) application is that there are two different approaches:

    1. Iterate over the list of children and set the appropriate state to tell Entity Framework whether to UPDATE, DELETE or INSERT, based on some logic such as the ID being null.

    2. Before calling the SaveChanges method, retrieve the object again from the database and set its members to the values of the updated object. As this is now connected and using the same Context as the retrieve, Entity Framework can do the comparison to determine the correct action to take.

    Obviously the second method requires an additional call to the database but involves less manual code. My question is what are other pros and cons of each method and are there any scenarios where one method is advantageous over the other method.

    Wednesday, January 17, 2018 9:01 PM

All replies

  • http://www.entityframeworktutorial.net/entityframework6/save-entity-graph.aspx

    You should just change the state and persist the object. You wouldn't be making a read of the record to update it if using T-SQL. It would just be the Update statement issued, no read first that would be the optimal approach  you should take that just changing the state provides in this scenario.

    The read on one connection on an update for an existing object by primary key, like one a single object, and update it on a new connection that changes state I do that, which is also being discussed in the link provided.

    Wednesday, January 17, 2018 9:52 PM
  • Hi Damien Fenton,

    SaveChanges does different things for entities in different states:

    • Unchanged entities are not touched by SaveChanges. Updates are not sent to the database for entities in the Unchanged state.
    • Added entities are inserted into the database and then become Unchanged when SaveChanges returns.
    • Modified entities are updated in the database and then become Unchanged when SaveChanges returns.
    • Deleted entities are deleted from the database and are then detached from the context.

    For more information, please refer to:

    https://msdn.microsoft.com/en-us/library/jj592676(v=vs.113).aspx

    Best regards,

    Zhanglong


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, January 18, 2018 1:14 AM
  • http://www.entityframeworktutorial.net/entityframework6/save-entity-graph.aspx

    You should just change the state and persist the object. You wouldn't be making a read of the record to update it if using T-SQL. It would just be the Update statement issued, no read first that would be the optimal approach  you should take that just changing the state provides in this scenario.

    The read on one connection on an update for an existing object by primary key, like one a single object, and update it on a new connection that changes state I do that, which is also being discussed in the link provided.

    Many thanks for your reply. I agree I would prefer to avoid an additional unnecessary read.

    In a list of child objects, I can use the object ID to determine whether to UPDATE or INSERT (i.e. perform INSERT if ID = null).

    How do you suggest I identify child objects that should be deleted from the list without first retrieving the object from the db so a comparison can be performed?

    Friday, January 19, 2018 1:39 PM
  • In a list of child objects, I can use the object ID to determine whether to UPDATE or INSERT (i.e. perform INSERT if ID = null).

    if the primary-key is integer based and using auto-increment of number used for primary-key assignment, then the primary-key property in the object would be 0 when object is instantiated 'new'. So ID = 0 is insert. ID > 0 is update. 

    How do you suggest I identify child objects that should be deleted from the list without first retrieving the object from the db so a comparison can be performed?

    If you know the object is to be deleted assuming that you were setting the delete state else where so that you can determine if the object was to be deleted at the time of the actual deletion of said object from the database, then I don't see why you can't set the object's state to 'deleted' in advance, which is just a flag in the object 

    And while iterating over objects in the collection, check the object's state for 'deleted' and do the actual deletion of the object at that time. 

    Saturday, January 20, 2018 8:02 PM