none
One-to-Many .Remove()? RRS feed

  • Question

  • I have what I consider a very simple data model and I'm struggling badly with EF 4.1 CF.

     

    My data model has two classes:

    public class Site {

    public int id { get; set; }

    public string name { get; set; }

     

    public ICollection<Building> buildings { get; set; }

    }

    public class Building {

    public int id { get; set; }

    public int siteId { get; set; }

    public string name { get; set; }

    }

     

    My configuration files are like this:

    public class SiteConfiguration : EntityTypeConfiguration<Site> {

    public SiteConfiguration() {

    HasMany(c => c.buildings).WithRequired().HasForeignKey(c => c.siteId);

    }

    }

     

    In my controller for MVC I simply want to remove a building from a site.  Here is my controller code:

    public ActionResult Delete(int id, int siteId) {

    var site = repo.GetById(siteId);

    var building = site.buildings.SingleOrDefault(c => c.id == id);

    ou.buildings.Remove(site);

    repo.Save(); 

    }

     

    My Error Message:

    The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted.

    Any thoughts or suggestions would be greatly appreciated. 

     

    Wednesday, June 22, 2011 3:24 PM

Answers

  • Hello,

    this is how EF works. Removing entity from navigation collection will not delete the entity (despite the mapping saying that parent is required). It will only remove the relation but dependent entity will still remain in the context as not deleted. I don't understand this very strange design decision. There are two solutions for this. First solution is manually deleting the dependent entity as well:

        ou.buildings.Remove(site);
        context.Sites.Remove(site); // Remove the site from the DbSet
        context.SaveChanges();

    The second workaround make this work as you expect but it is damn ugly because it requires you defining this in database model. EF will delete dependent entity by removing it from collection in parent entity only if you use Identifying relation.

    Best regards,
    Ladislav

    • Marked as answer by keroger2k Thursday, June 30, 2011 12:51 PM
    Wednesday, June 22, 2011 8:59 PM

All replies

  • Hello,

    this is how EF works. Removing entity from navigation collection will not delete the entity (despite the mapping saying that parent is required). It will only remove the relation but dependent entity will still remain in the context as not deleted. I don't understand this very strange design decision. There are two solutions for this. First solution is manually deleting the dependent entity as well:

        ou.buildings.Remove(site);
        context.Sites.Remove(site); // Remove the site from the DbSet
        context.SaveChanges();

    The second workaround make this work as you expect but it is damn ugly because it requires you defining this in database model. EF will delete dependent entity by removing it from collection in parent entity only if you use Identifying relation.

    Best regards,
    Ladislav

    • Marked as answer by keroger2k Thursday, June 30, 2011 12:51 PM
    Wednesday, June 22, 2011 8:59 PM
  • Hi Keroger2k,

    I am writing to check the status of the issue on your side. Would you mind letting us know the result of the suggestions?

    If you need further assistance, please feel free to let me know. I will be more than happy to be of assistance.

    Have a nice day.


    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, June 30, 2011 6:52 AM
    Moderator
  • I haven't figured out a better way to do this than the suggestion above.  It blows my mind this is how things work.  
    Thursday, June 30, 2011 12:51 PM