Let's say you have these classes in your entities.
public class Parent
{
public int ParentID { get; set; }
public virtual ICollection<Child> Children { get; set; }
}
public class Child
{
public int ChildID { get; set; }
public int ParentID { get; set; }
public virtual Parent Parent { get; set; }
}
And you have a user interface to update the Parent
along with its Children
, meaning if the user add new Child
then you have to insert, if the user edits an existing Child
then you need to update, and if the user removes a Child
then you have to delete. Now obviously if you use the following code
public void Update(Parent obj)
{
_parent.Attach(obj);
_dbContext.Entry(obj).State = EntityState.Modified;
_dbContext.SaveChanges();
}
it won't be able to detect the changes inside the Child
because EF cannot detect changes inside a Navigation Property.
I've been asking this question for like 4 times and get mixed answers. So is it actually possible to do this stuff without it getting complicated? This problem can fix the problem by separating the user interface between Parent
and Child
but I don't want to because merging both Child
and Parent
in one menu is pretty common in business application development and more user friendly.
UPDATE :
I'm trying the solution below but it doesn't work.
public ActionResult(ParentViewModel model)
{
var parentFromDB = context.Parent.Get(model.ParentID);
if (parentFromDB != null)
{
parentFromDB.Childs = model.Childs;
}
context.SaveChanges();
}
Instead of detecting changes inside the Children, EF won't be able to tell what to do with old child. For example if parentFromDB
has 3 children the first time I pull it from DB then I delete the 2nd and 3rd child. Then I'm getting The relationship could not be changed because one or more of the foreign-key properties is non-nullable
when saving.
I believe this is what happened :
The relationship could not be changed because one or more of the foreign-key properties is non-nullable
Which took me back to square one because in my scenario, I can't just fetch from the DB and update the entry and call SaveChanges
.
because EF cannot detect changes inside Navigation Property
This seems to be a somewhat distorted description of the fact that _dbContext.Entry(obj).State = EntityState.Modified
doesn't mark navigaton properties as modified.
Of course EF tracks changes in navigation properties. It tracks changes in properties and associations of all entities that are attached to a context. Therefore, the answer to your question, now positively stated...
Is it possible to update child collection in EF out of the box
... is: yes.
The only thing is: you don't do it out of the box.
The "out of the box" way to update any entity, whether it be a parent or a child in some collection is:
- Fetch entities from the database.
- Modify their properties or add/remove elements to their collections
- Call
SaveChanges()
.
That's all. Ef tracks the changes and you never set entity State
s explicitly.
However, in a disconnected (n-tier) scenario, this gets more complicated. We serialize and deserialize entities, so there can't be any context that tracks their changes. If we want to store the entities in the database, now it's our task to make EF know the changes. There are basically two ways to do this:
- Set the states manually, based on what we know about the entities (like: a primary key > 0 means that they exist and should be updated)
- Paint the state: retrieve the entities from the database and re-apply the changes from the deserialized entities to them.
When it comes to associations, we always have to paint the state. We have to get the current entities from the database and determine which children were added/deleted. There's no way to infer this from the deserialized object graph itself.
There various ways to alleviate this boring and elaborate task of painting the state, but that's beyond the scope of this Q&A. Some references:
- Generic repository to update an entire aggregate
- GraphDiff
Its cozs your doing it weirdly.
This requires Lazy loading for getting childs (obviously modify for your usage)
//get parent
var parent = context.Parent.Where(x => x.Id == parentId).SingleOrDefault();
wrote a whole test method for you. (apply to your case)
EmailMessage(parent) is the parent and it has none or many EmailAttachment's(child's)
[TestMethod]
public void TestMethodParentChild()
{
using (var context = new MyContext())
{
//put some data in the Db which is linked
//---------------------------------
var emailMessage = new EmailMessage
{
FromEmailAddress = "sss",
Message = "test",
Content = "hiehdue",
ReceivedDateTime = DateTime.Now,
CreateOn = DateTime.Now
};
var emailAttachment = new EmailAttachment
{
EmailMessageId = 123,
OrginalFileName = "samefilename",
ContentLength = 3,
File = new byte[123]
};
emailMessage.EmailAttachments.Add(emailAttachment);
context.EmailMessages.Add(emailMessage);
context.SaveChanges();
//---------------------------------
var firstEmail = context.EmailMessages.FirstOrDefault(x => x.Content == "hiehdue");
if (firstEmail != null)
{
//change the parent if you want
//foreach child change if you want
foreach (var item in firstEmail.EmailAttachments)
{
item.OrginalFileName = "I am the shit";
}
}
context.SaveChanges();
}
}
Update
Do your AutoMappper Stuff... as you said in your comment.
Then when you are ready to save and you have it back as the correct types ie once which represent entitys(Db) then do this.
var modelParent= "Some auto mapper magic to get back to Db types."
var parent = context.Parent.FirstOrDefault(x => x.Id == modelParent.Id);
//use automapper here to update the parent again
if (parent != null)
{
parent.Childs = modelParent.Childs;
}
//this will update all childs ie if its not in the new list from the return
//it will automatically be deleted, if its new it will be added and if it
// exists it will be updated.
context.SaveChanges();