Home/ Questions/Q 7618911
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T03:31:39+00:00

I’m a bit confused in regards to how EF’s dbContext works. If I do

  • 0

I’m a bit confused in regards to how EF’s dbContext works.

If I do something like _context.Persons.Add(_person) (assuming person is a valid entity), if I then (before calling _context.SaveChanges()) query Persons, will the person I just added be included in the results?

For example:

Person _person = new Person() {Firstname = "Bill", Lastname = "Snerdly"};
_context.Persons.Add(_person);
var _personList = _context.Persons.Where(p => p.Lastname.StartsWith("Sne"));

Whenever I try this, it seems as though the context loses track of the fact that I’ve added this new person to the context.

What confuses me is that if I edit an existing person and attach the person and set the state to modified, querying the context seems to keep track of the changes that were made and returns them in the results. For example:

//Assuming that Person 5 exists with the name William Snerdly
Person _person = new Person() {Id = 5, Firstname = "Bill", Lastname = "Snerdly"};
_context.Persons.Attach(_person);
_context.Entry(_person).State = System.Data.EntityState.Modified;
var _personList = _context.Persons.Where(p => p.Lastname.StartsWith("Sne"));

In this case, it seems like the person with the id of 5 will show up in the list with the name Bill instead of William. IOW, the context queried the data but retained the changes while in the first scenario, the context queried the data but ignored any added items. It just seems a bit inconsistant.

Am I understanding this correctly or am I missing something?

Thanks for your help with this.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    No, as it does not yet exist in the database. It will, however, be accessible through the ObjectStateManager of the ObjectContext, or alternatively, if you’re using the DbContext/DbSet wrappers, through the .Local property of the DbSet.

    In the case of the edit, you’re seeing the ORM’s first level cache at work. The query is executed against the database (and so compares against the values in there – your example would get even weirder if you modified the Lastname in the context, but still get the result from the query looking for the unmodified Lastname), but when its results are processed, first the ID of the returned entity is checked, and since the entity with that ID is already present in the context, you get that instance back. This is the default “AppendOnly” mode of operation.

    I don’t know what you want to do, but I had to understand all that when I wanted to validate my changes according to rules that needed to use the values of both loaded and unread entities. I ended up starting a transaction, saving the changes with the “None” options, doing my validation queries againt the database (which then contained the “merged” view of the data), and the rolling back the transaction if the data was invalid, or accepting the changes and committing the transaction otherwise.

    • 0