Entity Framework Instance tracking error with mapping sub-objects - is there an elegant solution?-CodePudding

Some 2 years ago I asked this question which was kindly solved by Steve Py.

I am having a similar but different problem now when mapping with sub-objects. I have had this issue a few times and worked around it, but facing doing so again, I can't help thinking there must be a more elegant solution. I am coding a memebership system in Blazor Wasm and wanting update membership details via a web-api. All very normal. I have a library function to update the membership:

            public async Task<MembershipLTDTO> UpdateMembershipAsync(APDbContext context, MembershipLTDTO sentmembership)
            {
                Membership? foundmembership = context.Memberships.Where(x =>x.Id == sentmembership.Id)
                    .Include(x => x.MembershipTypes)
                    .FirstOrDefault();
                if (foundmembership == null)
                {
                    return new MembershipLTDTO { Status = new InfoBool(false, "Error: Membership not found", InfoBool.ReasonCode.Not_Found) };
                }
                try
                {  
                    _mapper.Map(sentmembership, foundmembership, typeof(MembershipLTDTO), typeof(Membership));
                    //context.Entry(foundmembership).State = EntityState.Modified;  <-This was a 'try-out'
                    context.Memberships.Update(foundmembership);
                    await context.SaveChangesAsync();
                    sentmembership.Status = new InfoBool(true, "Membership successfully updated");
                    return sentmembership;
                }
                catch (Exception ex)
                {
                    return new MembershipLTDTO { Status = new InfoBool(false, $"{ex.Message}", InfoBool.ReasonCode.Not_Found) };
                }
            }

The Membership object is an EF DB object and references a many to many list of MembershipTypes:

public class Membership
{
    [Key]
    public int Id { get; set; }

    ...more stuff...

    public List<MembershipType>? MembershipTypes { get; set; }   // The users membership can be several types. e.g. Employee   Director   etc..
}

The MembershipLTDTO is a lightweight DTO with a few heavy objects removed.

Executing the code, I get an EF exception:

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

I think (from the previous question I asked some time ago) that I understand what is happening, and previously, I have worked around this by having a seperate function that would in this case update the membership types. Then, stripping it out of the 'found' and 'sent' objects to allow Mapper to do the rest.

In my mapping profile I have the mappings defines as follows for these object types:

            CreateMap<Membership, MembershipLTDTO>();
            CreateMap<MembershipLTDTO, Membership>();

            CreateMap<MembershipTypeDTO, MembershipType>();
            CreateMap<MembershipType, MembershipTypeDTO>();

As I was about to go and do that very thing again, I was wondering if I am missing a trick with my use of Mapper, or Entity Framework that would allow it to happen more seamlessly?

Thanks as always... Brett

CodePudding user response：

A couple of things come to mind. The first thing is that the call to context.Memberships.Update(foundmembership); isn't required here so long as you haven't disabled tracking in the DbContext. Calling SaveChanges will build an UPDATE SQL statement for whatever values change (if any) where Update will attempt to overwrite the entitiy(ies).

The issue you are likely encountering is common when dealing with references, and I would recommend a different approach because of this. To outline this, lets look at Membership Types. These would typically be a known list that we want to associate to new and existing memberships. We're not going to ever expect to create a new membership type as part of an operation where we create or update a membership, just add or remove associations to existing memberships.

The problem with using Automapper for this is when we want to associate another membership type in our passed in DTO. Say we have existing data that had a membership associated with Membership Type #1, and we want to add MemberShip Type #2. We load the original entity types to copy values across, eager loading membership types so we get the membership and Type #1, so far so good. However, when we call Mapper.Map() it sees a MemberShip Type #2 in the DTO, so it will add a new entity with ID #2 into the collection of our loaded Membership's Types collection. From here, one of three things can happen:

1) The DbContext was already tracking an instance with ID #2 and 
will complain when Update tries to associate another entity reference 
with ID #2.

2) The DbContext isn't tracking an instance, and attempts to add #2 
as a new entity. 

  2.1) The database is set up for an Identity column, and the new 
membership type gets inserted with the next available ID. (I.e. #16)

  2.2) The database is not set up for an Identity column and the
 `SaveChanges` raises a duplicate constraint error.

The issue here is that Automapper doesn't have knowledge that any new Membership Type should be retrieved from the DbContext.

Using Automapper's Map method can be used to update child collections, though it should only be used to update references that are actual children of the top-level entity. For instance if you have a Customer and a collection of Contacts where updating the customer you want to update, add, or remove contact detail records because those child records are owned by, and explicitly associated to their customer. Automapper can add to or remove from the collection, and update existing items. For references like many-to-many/many-to-one we cannot rely on that since we will want to associate existing entities, not add/remove them.

In this case, the recommendation would be to tell Automapper to ignore the Membership Types collection, then handle these afterwards.

_mapper.Map(sentmembership, foundmembership, typeof(MembershipLTDTO), typeof(Membership));

var memberShipTypeIds = sentmembership.MembershipTypes.Select(x => x.MembershipTypeId).ToList();
var existingMembershipTypeIds = foundmembership.MembershipTypes.Select(x => x.MembershipTypeId).ToList();
var idsToAdd = membershipTypeIds.Except(existingMembershipTypeIds).ToList();
var idsToRemove = existingMembershipTypeIds.Except(membershipTypeIds).ToList();

if(idsToRemove.Any())
{
    var membershipTypesToRemove = foundmembership.MembershipTypes.Where(x => idsToRemove.Contains(x.MembershipTypeId)).ToList();
    foreach (var membershipType in membershipTypesToRemove)
        foundmembership.MembershipTypes.Remove(membershipType;
}
if(idsToAdd.Any())
{
    var membershipTypesToAdd = context.MembershipTypes.Where(x => idsToRemove.Contains(x.MembershipTypeId)).ToList();
    foundmembership.MembershipTypes.AddRange(membershipTypesToAdd); // if declared as List, otherwise foreach and add them.
}

context.SaveChanges();

For items being removed, we find those entities in the loaded data state and remove them from the collection. For new items being added, we go to the context, fetch them all, and add them to the loaded data state's collection.