Implement RejectChanges() in DbContext

[ice1e0]

Story

There are many user requests for a function in DbContext class to reject or discard changes. See as well:

• https://stackoverflow.com/questions/5466677/undo-changes-in-entity-framework-entities
• https://stackoverflow.com/questions/16437083/dbcontext-discard-changes-without-disposing/16437305

Microsoft sample code: How to undo the changes in Entity Framework 4.1 and later

I first implemented a wrong version which I found online which caused terrible data loss. I was able to fix it with a similar solution as the Microsoft sample code is, see above.

Request

I would appreciate if a function DbContext.RejectChanges() or a similar one would be implemented in the official version of Entity Framework Core.

Further technical details

EF Core version: 2.1.4
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows
IDE: Visual Studio 2017 15.8.6

[mohamedmahmoudalemam]

I think this may be possible if there exists a state(backup) of database before and after each call for SaveChanges, and RejectChanges(state) return the database to the marked state.

[ajcvickers]

The recommended approach is to use a single DbContext instance for each unit-of-work, disposing it when done. If you need to discard all changes in a unit-of-work, then do so by disposing the context without saving.

[StrangeWill]

A use case I ran into:

• Attempting to do a lot of EF work
• Upon error, create a log entry and log it to the database
• If an error happens in the middle of EF work, the EF state will be invalid (missing objects, not cleaned out other objects, etc.)
• Log insert usually fails due to prior state

My options are:

• Inject a DbContext factory instead of a DbContext, request a new instance from the factory when logging errors, pray that the original DbContext isn't holding onto anything transaction-wise.
• Loop through the change tracker dropping everything.
• Inject the entire IServiceScopeFactory and manually create a new scope every time I need to dump a DbContext state (which sure, isn't often, but still).

Issue with 1) is that EF Core doesn't have a recommended way to even do this: #10694 (comment), so it's both a recommended way to accomplish a task, while being unsupported.

I agree 2) is kind of gross, without the context being designed for that (at least that's what I got from this issue), it may be doing some awful things we don't want it to. If it was a first-class supported flow this is would be super easy.

3. Is probably the "most DI friendly" while basically requiring us to be very explicit in scope, within basically every try/catch block that may need to throw out EF's state having it's own scope which is a bit rough.

---

Maybe I'm just missing something... but it seems like all options have pretty poor downsides of either support or code maintainability, so I think some more supported solution to this should be considered a bit more.

[giovinazzo-kevin]

+1. Not all DbContexts are made equal and some are long-lived objects that can't be disposed of very easily. Some are singletons, even, and they can't be disposed of without refactoring them into not being singletons in the first place.

Replacing them with factories and providers sure sounds like a pain - one that should be mitigated by the framework in this case.
Furthermore, given the SaveChanges syntax it would only make sense for there to be a DiscardChanges as well.

Another option would be to let each DbContext expose a method through which you can create a scoped sub-context, integrating the factory pattern seamlessly.

It's also worth mentioning that ScopedTransactions don't work at all here, despite old StackOverflow threads suggesting otherwise, and that manually iterating the ChangeTracker's entries sounds pretty risky, if not plain wrong.

This thread in particular is a great example of how confusing this all is - no two answers are the same!

[syndicatedshannon]

I have to agree with G3 and other requests here.

Because the UoW pattern crosses knowledge boundaries, we can't really ensure we don't save at the end of our scoped operation without a UoW-bound flag. RejectChanges() is one way that could be provided.

Otherwise, we have to ensure our exceptions surface all the way up, beyond the last SaveChanges() call, which breaks other SoC.

[syndicatedshannon]

Also, FYI, I see that RejectChanges() could easily lead to misunderstandings about the state of the context. Can we then apply more changes after rejection? etc. My prior comment about boundaries still applies, and I'm not sure what the solution is.

[dradovic]

As a possible work-around I would like to mention this library: EFCore.DbContextFactory.

[rmihael]

With Blazor Server, I have a common flow like this:

1. Create a DB context using the factory class (as recommended by https://docs.microsoft.com/en-us/aspnet/core/blazor/blazor-server-ef-core?view=aspnetcore-5.0#new-dbcontext-instances-5x);
2. Use Attach to bring some entities into the tracking context;
3. Make some changes in entities;
4. Call SaveChanges to persist these changes;
5. Dispose the DB context.

In case of any exception during step 3, I really want to roll back all modified entities to the state as they were initially. Currently, I am using the trick from https://stackoverflow.com/a/22098063/685808, but it feels hackish. With the rise of Blazor's popularity, that kind of workflow will happen more often. It makes sense to either provide some support for it in EF Core or suggest some workarounds in the documentation.

[KernelMC]

Does DbContext.ChangeTracker.Clear() work for this purpose? According the documentation it avoids to overhead of looping through the change tracker and detaching entities one by one. The downside to this is that all entities are detached, even those that were unmodified.

[nicholasyin]

What if my first call to SaveChanges failed, then I wanted to keep using the same context to do some other work, such as logging to database? In this case, my second call to SaveChanges, which is supposed to do ONLY logging would fail, because it would include all the previous changes that have failed the first call. The whole thing is indeed a unit of work.

[syndicatedshannon]

@nicholasyin : In that specific case I recommend using a separate context for logging. which probably has other benefits in your app as well.

[nicholasyin]

@nicholasyin : In that specific case I recommend using a separate context for logging. which probably has other benefits in your app as well.

Logging is just an example. The point is to have a unified calling style to save changes. So it should accommodate for both normal and exceptional scenarios. Therefore, using a separate context would require me to have a second context anyway, even for normal cases.