EF Core Attach/AttachRange 方法不起作用

Question

I 'm using EF Core 3.1.10. I have the following entities:

public class Request {
    public int Id { get; set; }
    public string Title { get; set; }
    public string ProjectId { get; set; }
    public List<RequestAttachment> Attachments { get; set; } = new List<RequestAttachment> ();
}

public class RequestAttachment {
    public int Id { get; set; }
    public int RequestId { get; set; }
    public Request Request { get; set; }
    public byte[] FileStream { get; set; }
    public string Filename { get; set; }
    public RequestAttachmentType RequestAttachmentType { get; set; }
    public int RequestAttachmentTypeId { get; set; }
}

public class RequestAttachmentType {
    public int Id { get; set; }
    public string Name { get; set; }
}

In my repository, I have a simple Update method:

    public async Task UpdateRequest (Request aRequest) {
        // I'm attaching aRequest.Attachments because they already exist in the database and I don 't want to update them here
        // Option 1 Not working
        // aRequest.Attachments.ForEach (a => theContext.RequestAttachments.Attach (a));
    
        // Option 2 Not working
        // theContext.RequestAttachments.AttachRange (aRequest.Attachments);
    
        // Option 3 Working
        aRequest.Attachments.ForEach (a => theContext.Entry (a).State = EntityState.Unchanged);
    
        theContext.Requests.Update(aRequest);
        await theContext.SaveChangesAsync ();
    }

Note that I'm attaching "aRequest.Attachments" because I don 't want to update Attachments. I only want to update aRequest. "aRequest.Attachments" already exist in the database that's why I 'm using Attach so they don't get re-added. But Attach and AttachRange do not work when a request has more than one attachment. It throws the following error:

The instance of entity type 'RequestAttachmentType' cannot be tracked because another instance with the key value '{Id: 1}' is already being tracked. When attaching existing entities, ensure that only one entity instance with a given key value is attached.

I don 't understand this error because I did not explicitly attach "RequestAttachmentType". The only thing I did was attaching its parent "aRequest.Attachments".

When I set the state manually like I did in Option 3, no error was thrown. I thought Attach is equivalent to theContext.Entry (a).State = EntityState.Unchanged. Why option 3 works but option 1 and 2 do not?

Answer 1

Try this:

var itemExist = await theContext.Requests.FirstOrDefaultAsync ( i=>i.Id == aRequest.Id);
 
 if (itemExist !=null)
{
var attachments=aRequest.Attachments;
aRequest.Attachments=null;
  theContext.Entry(itemExist ).CurrentValues.SetValues(aRequest);
await theContext.SaveChangesAsync();
aRequest.Attachments=attachments;
}

Answer 2

Working with detached entity graphs is going to continue to cause all kinds of headaches like this. Not only do you need to handle the scenario that you don't want to update/duplicate related entities, but you have to also handle cases where the DbContext is already tracking the entity you want to update. Sergey was on the right track there.

The problem is that you have a complete graph:

• Request
  • Atachment
    • AttachmentType
  • Attachment
    • AttachmentType

where you want to update details in Request and the Attachments...

One issue with "Update" is that it will dive the graph to look for entities that might need to be added/updated. On its own with a detached graph this will usually result in duplicate items being created. Hence "attaching" them first. The trouble here is where the DbContext is already tracking one or more entities in the graph. One key detail to remember about EF is that References are everything. Deserializing entity graphs is a painful exercise.

For example lets say we deserialize a Request Id 1, with 2 attachments, #1, and #2, where both have an AttachmentType of "Document" (AttachmentType ID = 14)

What you will end up is something that looks like:

Document 
{
    ID:1 
    ...
    Attachments
    {
        Attachment 
        {     
            ID:1 
            ...
            AttachmentType
            {
                ID: 14
            }
        }
        Attachment 
        {     
            ID:2 
            ...
            AttachmentType
            {
                ID: 14
            }
        }
    }
}

Without considering what the DbContext may or may not already be tracking prior to looking at these entities, there is already a problem. Attachment ID 1 and 2 are distinct objects, however they both reference an AttachmentType ID 14. When de-serialized, these will be 2 completely distinct references to objects that have an ID of 14.

A common surprise is where test code appears to work fine because the two attachments had different attachment types, but then fails unexpectedly when they happen to have the same type. The first attachment would have the DbContext tracking the first attachment's "Type". If the second attachment's Type was a different ID, then attaching that 2nd type would succeed so long as the Context wasn't tracking it. However, when set to the same ID the "already tracking entity with the same ID" pops up.

When dealing with disconnected entities you need to be very deliberate about references and explicitly handle whenever the DbContext is tracking a reference. This means consulting the DbSet Local caches:

public async Task UpdateRequest (Request aRequest) 
{
    var existingRequest = theContext.Requests.Local.SingleOrDefault(x => x.Id = aRequest.Id);
    if (existingRequest != null)
    {
        // copy values from aRequest -> existingRequest or Leverage something like automapper.Map(aRequest, existingRequest)
    }
    else
    {  
       theContext.Requests.Attach(aRequest);
       theContext.Entity(aRequest).State = EntityState.Modified; // Danger Will Robinson, make 100% sure your entity from client is validated!! This overwrites everything.
    }
    
    foreach(var attachment in aRequest)
    {
        var existingAttachment = theContext.Attachments.Local.SingleOrDefault(x => x.Id == attachment.Id);
        // Look for a reference to the attachment type. If found, use it, if not attach and use that...
        var existingAttachmentType = theContext.AttachmentTypes.Local.SingleOrDefault(x => x.Id == attachment.AttachmentType.Id);
        if (existingAttachmentType == null)
        {  
            theContext.AttachmentTypes.Attach(attachment.AttachmentType);
            existingAttachmentType = attachment.AttachmentType;
        }

        if(existingAttachment != null)
        {
             // copy values across.
             AttachmentType = existingAttachmentType; // in case we change the attachment type for this attachment.
        }
        else
        {
            theContext.Attachments.Attach(attachment);
            theContext.Entity(attachment).State = EntityState.Modified;
            attachment.AttachmentType = existingAttachmentType;
        }   
    }              
    await theContext.SaveChangesAsync ();
}

Needless to say this is a lot of messing around to check and replace references to either get the DbContext to track detached entities or replace the references with tracked entities.

A simpler option is to leverage Automapper to establish a configuration for what fields can be updated from a source (ideally a ViewModel, but you can use an entity graph as a source) to a destination. (Entities tracked by the DbContext)

Step 1: Configure Automapper with the rules about what to update for a Request -> Attachments graph.. (Not shown)

Step 2: Load tracked entity graph, and the applicable AttachmentTypes:

var existingRequest = theContext.Requests
    .Include(x => x.Attachments)
        .ThenInclude(x => x.AttachmentType)
    .Single(x => x.Id == aRequest.Id);
var referencedAttachmentTypeIds = aRequest.Attachments.Select(x => x.AttachmentTypeId)
    .Distinct().ToList();
var referencedAttachmentTypes = theContext.AttachmentTypes
    .Where(x => referencedAttachmentTypeIds.Contains(x.Id))
    .ToList();

Getting the list of attachment types only applies if we can change an attachment's type, or are adding attachments.

Step 3: Leverage Automapper to copy across values

mapper.Map(aRequest, existingRequest);

If Attachments can be updated, added, and/or removed you will need to handle those scenarios against the existingRequest. Here we reference the loaded set of AttachmentTypes.

Step 4: Save Changes.

The primary benefits of this approach is that you do away with the constant checking for existing references and the consequences of missing a check. You also configure the rules about what values can legally be overwritten when calling the Automapper Map call so only values you expect are copied from the source to the existing data record. This also results in faster Update queries as EF will only build statements for the values that actually changed, where using Update or EntityState.Modified result in SQL UPDATE statements that update every column.