How do I detach objects in Entity Framework Code First?

entity-framework entity-framework-4.1 ef-code-first

There is no Detach(object entity) on the DbContext.

Do I have the ability to detach objects on EF code first?

Slauma

This is an option:

dbContext.Entry(entity).State = EntityState.Detached;

Can I do this when retrieving objects that returns an IQueryable?

@Lol coder: I am not sure if I understand you right, but entity must be a materialized object of a type which is part of your model classes (Person, Customer, Order, etc.). You cannot directly pass in an IQueryable<T> into dbContext.Entry(...). Is that the question you meant?

@EladBenda: It depends. If you want to detach an object that is already attached to the context, set the state to Detached. If you want to load entities from the DB without attaching them at all to the context (no change tracking), use AsNoTracking.

@kjbartel : this is the expected behavior, since the entity has no link with the context.

@rcdmk If you get an entity with AsNoTracking like in the other answer then lazy loading will still work. This method will not.

saluce

If you want to detach existing object follow @Slauma's advice. If you want to load objects without tracking changes use:

var data = context.MyEntities.AsNoTracking().Where(...).ToList();

As mentioned in comment this will not completely detach entities. They are still attached and lazy loading works but entities are not tracked. This should be used for example if you want to load entity only to read data and you don't plan to modify them.

@Ladislav: This is indeed probably what Lol coder meant. I've never used and thought about this method although I often load object lists and dispose the context at once, something like using(ctx){ return ctx....ToList(); }. In such cases using AsNoTracking() would make much sense because I'd save filling up the object context unnecessarily. I guess it would probably have a performance and memory consumption benefit especially for large lists, right?

@Slauma: Yes it has performance benefit. That is actually why this method exists. Using this approach in ObjectContext API is little bit more complicated.

Does this disable lazy loading?

Actually this will not disable lazy loading it will only disable change tracking and improve performance = entity is still attached. I found it after answering this question so you should mark @Slauma's one as a valid answer.

This is what I want. I want lazy loading and the ability to only modify a detached entity.

The Fabio

Both previous answers provide good instructions, however, both might leave you with the entities still loaded into EF's context and/or its Change Tracker.

This is not a problem when you are changing small data sets, but it will become an issue when changing large ones. EF would have increased memory and resource usage, which in turn would reduce the procedure performance as it uses more data/entities.

Both other approaches are valid but, In this case, Microsoft recommends cleaning the Change tracker instead of detaching the entities individually

Clearing the Change tracker on the data changing loop (which changes a chunk of data for instance) can save you from this trouble.

context.ChangeTracker.Clear();

This would unload/detach all entities and its related changeTracker references from the context, so use with care after your context.SaveChanges().

both would leave you with the entity still loaded into EF's Change Tracker -- That's not true. Detaching an object removes it from the change tracker. If the entity is a lazy-loading proxy then it has a reference to the context, but that's not the same as being attached to it (Ladislav's phrasing is a bit ambiguous here).

Hi Gert, You can verify it with a quick test. The entity remains in the ChangeTracker with a state of detached. Similar to a memory leak (but unfortunately by design..). Calling the Clear command removes all of the instantiated entity objects from the Context

Of course the state is detached, what else? Even if you create a brand new entity that has never even seen a context its state is detached. It's just EF's way of saying: don't know this one, nothing to do with it. The alternative would be to throw an exception when verifying the state of any entity outside the context. Of course nobody wants that.

and yet EF retains it in memory detached like a memory leak

Thanks @TheFabio - this solved a massive performance issue when bulk inserting very large graphs in EF. To solve it, I used your line after saving each entity, and the performance increase and memory usage improvement was awesome. Thanks!

How do I detach objects in Entity Framework Code First?

Follow WeChat

Want to stay one step ahead of the latest teleworks?

相似问题

Platform

Support

Links

Contact US