madatanic
madatanic

Reputation: 1790

Move child entities to a new parent entity

What is the best way to move child entities from one parent entity to another? Is there a method inside the ObjectContext or DbContext that allows us to accomplish this?

public class Person
{
   public int PersonId
   public ICollection<Car> Cars
}

public class Car
{
   public int CarId
   public string Color
}

EDIT: I'm currently using EF 4.0 model first with POCO template.

Upvotes: 3

Views: 4673

Answers (2)

D Mentia
D Mentia

Reputation: 11

With modern EFCore, you can do this very simply by Attaching the new Parent entity, which contains Children with IDs in them. It will reassign the FK of the child (or create it if no ID is specified), and create the new Person, all in one go

Ex:

var newOwner = new Person { 
    Cars = new List<Car> { 
        new Car { carId = theCarToMove.carId } 
    } 
};
Context.Attach(newOwner);
await Context.SaveChangesAsync();

Beware that Attach can cause problems if your Context isn't truly transient, but as a bandaid you could always clear the ChangeTracker before attempting an Attach

EDIT: After trying this, I found that for some DB providers, it doesn't work directly. Instead, try:

foreach(var car in carsToMove)
{
    Context.Attach(car);
    car.Owner = newOwner;
}
Context.Attach(newOwner);
await Context.SaveChangesAsync();

Order matters when using Attach. The SQL query built by EFCore builds in reverse of the order you set it up in C#. If you attach the newOwner before the cars, the CREATE query is the last thing in the SQL, after the UPDATE for the cars. If this is the case, the cars can't UPDATE to the new OwnerId, because the newOwner did not have an ID at that point in the query. I believe this is also what's happening with the first code block, with some providers

Upvotes: 1

dmusial
dmusial

Reputation: 1564

I'd say what you want to accomplish is changing the owner of the car in this example. If there are no serious cons against adding a back reference to Person in the Car i'd go with something like:

public class Car
{
   ...
   public virtual Person Owner { get; protected set; }

   public void ChangeOwner(Person newOwner)
   {
          // perform validation and then 
          Owner = newOwner;
          // maybe perform some further domain-specific logic
   }
}

NOTE: the protected setter is to enforce calling the ChangeOwner method by external consumers. EF wil be able to set it properly thanks to the autogenerated proxies for POCO classes (assume you use them).

EDIT: In case there is no possibility to add a back reference to Person, you still have have the same goal looking from the domain logic perspective. You just want to change owner of a car. Such operation involves two entites so i'd probably go with a method placed somewhere outside the entity (regardless of where it should be placed in a well designed system):

public void ChangeCarOwner(Person originalOwner, Person newOwner, int carId)
{
    Car car = originalOwner.RemoveCarOwnership(carId);
    newOwner.AddCarOwnership(car);
}

public class Person
{
    ...
    public Car RemoveCarOwnership(int carId)
    {
        Car car = this.Cars.Single(c => c.Id == carId);
        this.Cars.Remove(car);
        return car;
    }
}

This is just a conceptual piece of code and it most certainly can be written better (making sure the old owner actually owns the car etc.), but i just wanted to present an idea of how would i approach it. I also ommited the implementation of AddCarOwnership cause i suppose it's pretty strainghtforward. I introduced those methods cause adding and removing ownership may trigger some further logic "inside" a particular person.

Upvotes: 2

Related Questions