What effect do the different EF 4 SaveOptions have on the ObjectContext?

I'm trying to resolve an error very similar to the one outlined here:

InvalidOperationException when calling SaveChanges in .NET Entity framework

It appears that the solution (which I have not tried yet, admittedly) is to pass System.Data.Objects.SaveOptions.None as the SaveOptions parameter for the SaveChanges() method.

So before I do that, I'm trying to understand exactly how the different SaveOptions work (None, AcceptAllChangesAfterSave, DetectAllChanges). I haven't been able to find a clear explanation of it however, nor am I sure what the default is. Can anyone clarify开发者_如何学Go?

Thanks!

UPDATE: I have posted the actual problem question here: System.InvalidOperationException when trying to iteratively add objects using EF 4

Short correction for

SaveOptions.DetectChangesBeforeSave : this is the default. When you do ObjectContext.SaveChanges(), the method DetectChanges() is called to synchronized attach entities in the OSM.

SaveChanges is an overloaded version of SaveChanges(SaveOptions optsions) method, where this parameterless version calls this

SaveChanges(SaveOptions.DetectChangesBeforeSave | SaveOptions.AcceptAllChangesAfterSave)

SaveOptions is a Flag enum and in conclusion, SaveOptions.DetectChangesBeforeSave | SaveOptions.AcceptAllChangesAfterSave is the default of SaveChanges() not the DetectChangesBeforeSave

In a nutshell (from what I understand):

SaveOptions.DetectChangesBeforeSave : this is the default. When you do ObjectContext.SaveChanges(), the method DetectChanges() is called to synchronized attach entities in the OSM.

SaveOptions.AcceptAllChangesAfterSave : When you do ObjectContext.SaveChanges(), the method AcceptAllChanges() is called - which is the guts of the OSM, where the entities in the graph are iterated, addresses and set to Unchanged/Detached.

SaveOptions.None : When you do ObjectContext.SaveChanges(), changes are saved immeditately - no synchronization at all. Whatever is in the graph is what will be saved.

In my experience I have not changed this - I've left it as the default (DetectChangesBeforeSave).

Sometimes with POCOs I have heard you need to explicitly call DetectChanges, but I've never seen a recommendation/solution to change the SaveOptions to none.

Are you sure the solution in that question is to set SaveOptions to none? Maybe you should provide detail (or ask a separate question) as to the error you're getting, as a change like this will affect your entire persistence layer.