locked
RejectChanges functionality in ADO.NET Entity Framework RRS feed

  • Question

  • Hello,

    I would like to know if the "RejectChanges" functionnality will be available in ADO.NET Entity Framework.

    For me, "RejectChanges" is used to UNDO the user modifications. "RejectChanges" is a different scenario than "Reloading" the entity because "reloading" means potentially "getting" the other users modifications made on the entity.

     

    If ADO.NET Entity Framework goal is to offer an alternative to DataSet/DataTable then I think the RejectChanges is needed.

    Unfortunaltly, I noticed that the "RejectChanges" method on class ObjectStateEntry (in ADO.NET Entity Framework in January 2007 CTP) had disapeared !

     

    Will it be possible to perform a "RejectChanges" in the final version ?

     

    Thanks for your help.

     

    Wednesday, August 8, 2007 7:57 AM

Answers

  • Unfortunately, no.  The first release of the EntityFramework will not have RejectChanges support.  The problem here is that the general case of a complex object graph which might have referential integrity constraints and a variety of other subtle requirements makes reject changes more difficult than it is in the DataSet/DataTable.  We understand the value of the feature and hope to add it in a future relase of the EntityFramework, but it's not currently slated for the first release.  There are just too many other things that are a higher priority.

     

    It is still possible to build an undo system on top of the EntityFramework, and doing so for a particular application will be easier (given knowledge of the model involved, etc.) than it is to solve the general problem across all models.  This does, however, mean more code for you to write.  Sorry I don't have better news.

     

    - Danny

    Wednesday, August 8, 2007 9:16 PM

All replies

  • Unfortunately, no.  The first release of the EntityFramework will not have RejectChanges support.  The problem here is that the general case of a complex object graph which might have referential integrity constraints and a variety of other subtle requirements makes reject changes more difficult than it is in the DataSet/DataTable.  We understand the value of the feature and hope to add it in a future relase of the EntityFramework, but it's not currently slated for the first release.  There are just too many other things that are a higher priority.

     

    It is still possible to build an undo system on top of the EntityFramework, and doing so for a particular application will be easier (given knowledge of the model involved, etc.) than it is to solve the general problem across all models.  This does, however, mean more code for you to write.  Sorry I don't have better news.

     

    - Danny

    Wednesday, August 8, 2007 9:16 PM
  • Hi, same question - two years on!

    Will there be a RejectChanges() anytime soon? or perhaps a simple IsDirty() ?

    thanks
    mark
    Tuesday, September 22, 2009 8:22 AM
  • I'd like to understand what you mean by IsDirty()...  Based on my naive understanding of that, I think we already have it in the form of checking the entitystate of an object.  If there's something more you need, please help me understand better what it is.

    The answer to the RejectChanges question is, sadly no.  We have been working on many, many things.  This one has stayed on the list, but isn't there yet.  The self-tracking entities work we are doing might help here.  Some people have suggested that you could use self-tracking entities for scenarios like where you want to data bind to entities and have a cancel button which requires the ability to reject changes by serializing and deserializing a graph of related entities in order to make a copy which is not attached to the state manager.  Then you can databind to that copy.  If the user cancel's the dialog, then you just throw the whole thing away.  If they commit the change, then you can use the STE ApplyChanges capability to role your changes back into the context and save them.

    Doing this directly with a reject changes kind of mechanism, though, just isn't something we've been able to get into EF4.

    - Danny
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, October 2, 2009 8:27 PM
  • Hi Danny,

    You know, as much as I love the whole concept of the Entity Framework, you guys do yourselves no favors when you ignore fundamental things that people need to do in their applications.

    First, it was the inability to databind to navigation properties using the existing WinForms controls (thank goodness you've finally had the sense to add foreign keys for these scenarios, & yes, I managed to use the hand-written partial class properties method to get it working), now it's something as basic as being able to "undo" changes.

    Do you guys actually build any real-world-type applications yourself during your testing of the framework? If you did, you might realise the problems that people who are trying (sometimes desperately) to use the new framework to replace previous methods face. I just don't get how you can expect people to use something that is missing such fundamental functions.

    The framework knows enough about managing changes to be able to handle updates, surely it must know enough to be able to "undo" changes as well.

    It's SO frustrating!

    Yann
    Tuesday, November 17, 2009 6:24 AM
  • I need it too.

    mhw11
    Saturday, December 12, 2009 2:58 AM
  • Not exactly sure what everybody is so upset about... you can use the ObjectStateManager to pretty easily implement undo functionality. Here's a simple example that reverts changes for modified items, reverts changes for deleted items (in case any items were first modified then deleted), 'undeletes' deleted item, and removes new items. The Example:

    public static void RejectChanges()
            {
                foreach (ObjectStateEntry ose in dbContext.DataContext.ObjectStateManager.GetObjectStateEntries(EntityState.Modified | EntityState.Deleted))
                {
                    try
                    {
                        foreach (string property in ose.GetModifiedProperties())
                        {
                            ose.RejectPropertyChanges(property);
                        }
                    }
                    catch(NullReferenceException)
                    {
                        //iteration done, do nothing;
                    }
                }
                foreach(ObjectStateEntry ose in dbContext.DataContext.ObjectStateManager.GetObjectStateEntries(EntityState.Deleted))
                {
                    ose.ChangeState(EntityState.Unchanged);
                }
                foreach (ObjectStateEntry ose in dbContext.DataContext.ObjectStateManager.GetObjectStateEntries(EntityState.Added))
                {
                    ose.RelationshipManager.GetAllRelatedEnds().FirstOrDefault().Remove(ose.Entity);
                }
            }


    • Proposed as answer by YZaX Wednesday, September 11, 2013 10:00 PM
    Wednesday, September 11, 2013 3:46 PM