Develop Reference

How can I attach an entity to the context when one of its children is already attached?

Background
In my application we were running into issues when trying to add a new entity with existing children to the database after mapping it from a DTO using AutoMapper. The entity and its children were not attached to the context, and so the children would be treated as new and EF would attempt to insert duplicates. My solution to this was to automatically attach an entity to the context whenever an object was mapped to a BaseEntity type (BaseEntity is the base class for all of our Model objects, it has an Id property and nothing else). Here is the code:
public TDestination Map<TDestination>(object source) where TDestination : class
{
var result = _mapper.Map<TDestination>(source);
if (typeof(TDestination).IsSubclassOf(typeof(BaseEntity)) && result != null)
_context.Attach(result); //_context is a DbContext
return result;
}
This worked fine in my initial test cases, but now I've run into an issue where the entity I'm attaching has a child that is already attached to the context. This throws "The instance of entity type 'MyChildEntity' cannot be tracked because another instance with the same key value for {'Id'} is already being tracked.".
How can I attach an entity to the context when a child is already attached? I'm trying to keep this method extremely generic so that it can be used by any object that we are trying to map from a DTO to a BaseEntity.
What I've Tried
I've tried grabbing the associated EntityEntry and recursively detach all of its children using the following method before attempting to call Attach():
private void DetachChildren(EntityEntry entity)
{
foreach (var member in entity.Members.Where(x => x.CurrentValue != null))
{
if (IsBaseEntityType(member.CurrentValue.GetType()))
{
var childEntity = _context.Entry(member.CurrentValue);
childEntity.State = EntityState.Detached;
DetachChildren(childEntity);
}
}
}
I've confirmed that this loop does reach the problem child and sets its state to detached, but I still end up getting the same error when calling Attach().

Welcome to the hell that is working with detached entities.
Automapper can be leveraged to update existing entities rather than forming an entity and attaching it. Given an object like an Order:
public void UpdateOrder(OrderDTO orderDTO)
{
var order = _context.Orders.Single(x => x.OrderId = orderDTO.OrderId);
_mapper.Map(orderDTO, order);
_context.SaveChanges();
}
The benefits of this approach is that it handles whether the order happens to be tracked or not, asserts the order exists for something like an Update where it is assumed it does, and when SaveChanges runs, only the fields that actually changed will be updated. If only 1 field changed, the update statement updates that single field. Attaching a new object and setting EntityState to Modified will update all fields. This could introduce unexpected attack vectors to change data you don't expect since a DTO needs to pass enough info to construct a whole entity to avoid unintentionally #null-ing data. The mapping from DTO to entity should ensure that only editable fields are copied across.
In the case where the OrderDTO will contain one or more child collections to update, you will likely need to use a mapping that excludes those collections, then use AfterMap in the mapping configuration to inspect the child collection for new vs. existing vs. removed entities and handle those accordingly. (Add vs. mapper.Map vs. Remove)
Generally the updates can be structured to perform atomic operations that make the entity interactions as straight forward as possible. For instance UpdateOrderDetails(orderDTO) would update information about the order itself, where there would be separate methods such as AddOrderLine(newOrderLineDTO) vs. UpdateOrderLine(orderLineDTO) vs. RemoveOrderLine(orderLineId) etc. rather than having all order line operations and other related changes done through a single UpdateOrder method accepting a whole modified object graph.
The alternative when dealing with graphs and the possibility of tracked entities is that you need to check each and every related entity against the DbSet's .Local or other means to check to see if the entity is tracked. If it is, then you have to replace the references and copy any applicable changes to the already tracked entity. Telling a DbContext to ignore an existing entity isn't always a simple matter as there can be references to that entity in other tracked entities. Generally you'll want to detect a tracked entity reference then update your references to use that tracked reference and update it as needed. It is lots of mucking around with references, and definitely does not work well with Generic methods
Generic operations are tempting from a DNRY standpoint, but dealing with situations where some entities might be tracked vs. not, and then handling type mismatches etc. (source = object = can be anything..) adds a lot of complexity in place of simpler methods to handle operations.

The ObjectContext instance has been disposed and can no longer be used

I've seen this question asked a million times, but every single suggestion I've encountered I already seem to have covered.
I have entity framework in my MVC solution, and I have a 'repository' which attempts to retrieve a collection of MyObjects:
public static List<MyObject> GetMyObjects()
{
using (var context = new MyEntities())
{
return context.MyObjects.Include("Contact").OrderByDescending(o => o.Date).ToList();
}
}
I call this method as part of a controller action which attempts to serialize it:
public JsonResult All()
{
return Json(MyRepository.GetMyObjects(), JsonRequestBehavior.AllowGet);
}
And I get the following error:
The ObjectContext instance has been disposed and can no longer be used for operations that require a connection.
I don't know where to turn on this one, I appreciate entity framework 'lazy-loads' relational data sets if and when they're needed, and I appreciate attempting to serialize the whole collection would indeed attempt to load these (outside of the using statement), but I have the 'Include' there.
What I've Tried
I've tried the 'include', I've also ensured no other associations are part of the MyObject class (i.e. I have no other Include()s to write).

To avoid this you have some options.Don't declare your navigation properties as virtual or disable Lazy Loading behavior on your context. Lazy loading is enable by default and is achieved by creating instances of derived proxy types and then overriding virtual properties to add the loading hook. So, if you want to work with a serializer I recommend you turn off lazy loading:
public class YourContext : DbContext
{
public YourContext()
{
this.Configuration.LazyLoadingEnabled = false;
}
}
These links can help you to understand better what I explain in my answer:
Loading Related Entities
Requirements for Creating POCO Proxies
If you remove the virtual keyword from your navigation properties, the POCO entity not meet the requirements described in the second link, so, EF won't create a proxy class to lazy load your navigation properties. But if you disabled lazy loading, even when your navigation properties are virtual, they won't be loaded in any entity. It's good idea disable lazy loading when you are using a serializer. Most serializers work by accessing each property on an instance of a type.
As a third option you could use the JsonIgnore attribute on your navigation properties that you don't want to be serialized as part of your entity, but as I said before, the best option is disable lazy loading.

When you use Include and using Lazy loading, and wrap the dbContext in a Using statement, then once it tries to get the linked objects, the dbContext is already disposed.
You can try eager loading of the navigation property like this:
IQueryable<MyObjects> query = db.MyObjects.Include(m => m.Contact);
Or you could take out the Using statement, as it is limiting your lazy loading...

I had the same problem and solved like below;
I created a new object and put the values I am gonna use after getting object from db.
Example Code:
var listFromDb= db.XTable.Where(x => x.Id > 5).ToList();
var list = new List<Package>();
foreach (var item in listFromDb)
{
var a = new Package()
{
AccountNo = item.AccountNo,
CreateDate = item.CreateDate,
IsResultCreated = item.IsResultCreated,
};
list.Add(a);
}

entity framework load only parent entity

I need to load an entity from Entity Framework(EF) but I only need the entity itself, I don't need any childs. I'm having troubles sending an object trought sockets because of the weight of the object.(Any suggestion about this?)
I'm using this code to get the list of objects I need:
…
private static DBEntities context = new DBEntities();
listaPlatos = context.PLATO.ToList();
…
My problem is that each object "PLATO" has others objects as childs. I want to ignore that childs and get only the "PLATO" entity.
Thanks.

Since you don't use an explicit loading of children, I guess lazy loading may cause you problems.
Check out
context.Configuration.LazyLoadingEnabled = false;
Here is a relevant link:
http://msdn.microsoft.com/en-us/data/jj574232.aspx

I think the problem is the serializer. A solution could be to use another class which is a pure POCO DTO class (this is always a best practise when you serializing something over the wire (sockets, WCF, whatever)).
var listaPlatos = context.PLATO.Select(x => new PlatoDto {
Prop1 = x.SomeProp
});

Why is EF returning a proxy class instead of the actual entity?

I'm having trouble with entity framework returning Proxies when I want the actual entity class. The first time I run my code everything runs properly (no proxies), but every iteration afterwards one of my DbSets always returns proxies instead of the actual type.
I dispose of the context after every iteration, so I don't understand why the first time through it works, and every time after doesn't.
My code fails on this line. All my POCOs have the Table attribute set, but because it is returning a proxy class there is no table attribute.
TableAttribute attrib = (TableAttribute)attributes.Single();
Is there some behind the scenes static magic in the DbContext that lives after I destroy the object?
I move my objects into memory using the following
MajorClasses = ctx.MajorClasses.ToArray();
I also tried
MajorClasses = ctx.MajorClasses.AsNoTracking().ToArray();
In my OnModelCreating I have the following set
base.Configuration.ProxyCreationEnabled = false;
base.Configuration.LazyLoadingEnabled = false;

You can set ObjectContext.ContextOptions.ProxyCreationEnabled to false. This will prevent you from using some of EFs fancy features like lazy loading and I believe change tracking.
As far as your app cares, it should be able to treat the proxies just like the types they represent. Is there a specific issue you are having?
Edit
We have some code that requires the POCO type instead of the proxy type and we do the following to detect if the current type is a proxy.
if (entityType.BaseType != null && entityType.Namespace == "System.Data.Entity.DynamicProxies")
{
entityType = entityType.BaseType;
}

To turn off proxy creation in Entity Framework 5 you can use the following,
_dbContext.Configuration.ProxyCreationEnabled = false;
Simply set this property once before using the context to pull data.

By default, EF uses Change Tracking and uses an in-memory cache of all entities. You can use different Merge Options when working with EF. By default, EF 4.1 is set to AppendOnly Merge Option. As I understand, this means that if you have already queried an entity, subsequent queries will get the entity from the cache (if there are no detected changes in the database). So you might be seeing the cached entity coming back.
In EF 4.1, you can use NoTracking Merge Option. This will go to the database for every call.

In EF 6.1.3 you can get the right type using
using (var context = new BloggingContext()) {
var blog = context.Blogs.Find(1);
var entityType = ObjectContext.GetObjectType(blog.GetType());
}
Note that if the type passed to GetObjectType is an instance of an entity type that is not a proxy type then the type of entity is still returned. This means you can always use this method to get the actual entity type without any other checking to see if the type is a proxy type or not.
From MSDN

simple solution is you are missing some object that must be included and also do this one before getting values
_dbContext.Configuration.ProxyCreationEnabled = false;

In my case this issue was fixed by setting Lazy Loading Enabled to false.
Open the .edmx (diagram)
Hit F4 to bring up the properties
Set Lazy Loading Enabled to false
Save and rebuild

Lazy loading not working for POCO classes in Entity Framework

Please help me, I am new to EF.Lazy loading for POCO objects doesn't seem to be working.
My POCO classes are in a sepearte assembly, other than the one one for Data access(i.e DAL)
The Data Acess layer simply wraps the calls made to the EF's object context. Please see the code below
public FilterMaster GetFilter(long ID)
{
FilterMaster entity = new FilterMaster();
try
{
using (var context = new RadarEntities())
{
//context.ContextOptions.LazyLoadingEnabled = false;
//context.ContextOptions.ProxyCreationEnabled = true;
entity = context.FilterMasters.SingleOrDefault(filter => filter.ID == ID);
//context.FilterMasters.Include(
context.LoadProperty(entity, "SQLQuery");
}
}
When DAL call is completed, the ObjectContext is lost, and when I tried to fetch the related child objects of the Root POCO class, I get null.
I've tried explicitly enabling ProxyCreation, EnabledLazyLoading, checked the proxy clases generated are not sealed and all the related properties are marked virtual (as suggested on some other links).
-As the lazy load was not working, I thought of eagerly loading all the related POCO objects, so tried invoking LoadProperty method, which works.
Q1: Am I Imissing something the lazy loading isn't working?
Q2: If I want to expelictly load all the related child objects the will have to call the LoadProperty method for all properties or there is any simpler way?

You are disposing your ObjectContext. This is what is preventing you from using LazyLoading. If you need LazyLoading, the class containing GetFilter should create an ObjectContext when it is created, implement IDisposable, and dispose of the ObjectContext when it is disposed.

Q1: Am I Imissing something the lazy loading isn't working?
It's working but there is no magic involved - underneath a proxy is created for you which will try to retrieve the property value from the database for you on the first access.
For EF the database connection is represented by the context, which you currently dispose automatically at the end of your using block. Without database connection EF cannot lazily retrieve the properties and hence lazy loading won't work.
You will have to keep the context alive until you have accessed all the properties you need to access for lazy loading, or alternatively eagerly load those properties.
Q2: If I want to explicitly load all the related child objects the
will have to call the LoadProperty method for all properties or there
is any simpler way?
Yes, you can specify an Include() query to eagerly retrieve properties, in your case that would be:
entity = context.FilterMasters
.Include("SQLQuery")
.SingleOrDefault(filter => filter.ID == ID);