EF6 virtual objects no longer available

Question

I have a new Problem, that I don't know how it came up.

public static int SaveNewProjectGraphic(string svgString, int pageId, ApplicationDbContext db, string user = "System")
    {
        db = new ApplicationDbContext();   //tried with new and with db-context given from controller-action
        LayoutGraphic layoutGraphic = new LayoutGraphic()
        {
            byUser = user,
            EditorSettingId = pageId,
            SvgString = svgString
        };

        db.LayoutGraphics.Add(layoutGraphic);
        db.SaveChanges();
        layoutGraphic.EditorSetting.Project.LastChange = DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss");
        layoutGraphic.EditorSetting.Project.byUser = user;
        db.Entry(layoutGraphic.EditorSetting.Project).State = EntityState.Modified;
        string newId = layoutGraphic.Id.ToString();
        string newSvgString = svgString.Replace("newGraphicId", "g" + newId);
        layoutGraphic.SvgString = newSvgString;
        db.Entry(layoutGraphic).State = EntityState.Modified;
        db.SaveChanges();
        return layoutGraphic.Id;
    }

In the static function above, I create a new record.
After db.SaveChanges() I normally got the virtual record (EditorSetting), that is associated with the new record.
Now I could use this association to Change some properties (fields) of that record.

I am 100% sure that this worked before but somehow this is broken (not only on this model), so I only get a null-reference-exception on EditorSetting (And of Course Project, which is associated with Editorsetting).
I have no idea, what I have done :-(

Here the LayouGraphic-model (Detail):

public class LayoutGraphic : BaseEntity
{
    [Display(Name = "SVG")]
    public string SvgString { get; set; }

    public int EditorSettingId { get; set; }
    public virtual EditorSetting EditorSetting{ get; set; }
}

And the associated master-model:

public class EditorSetting
{
    //defaults setzen
    public EditorSetting()
    {
        ViewBox = "0 0 600 500";
        Created = DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss");
        LastChange = DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss");
    }

    public int Id { get; set; }
    public int ProjectId { get; set; }
    public virtual Project Project { get; set; }

    public string ViewBox { get; set; }
    public string ViewName { get; set; }
    public string Pagenumber { get; set; }

    public string Created { get; set; }
    public string LastChange { get; set; }
    public string byUser { get; set; }

    //1:n Beziehung zu Unterfunktionen
    public virtual ICollection<SubFunction> SubFunctions { get; set; }
}

Any ideas? Thanks Carsten

Answer 1

This behavior difference is a consequence of long-living DbContexts. By declaring a new DbContext in the method, you will never see the EditorSetting reference updated by setting the EditorSettingId FK on the entity and saving it.

When you use a longer-lived DbContext then you may see it updated, provided the DBContext knows about it. (The referenced EditorSetting is a tracked entity in the DbContext)

For example:

Assuming we have a Parent and Child entity. Parent contains a collection of Children, and Child contains a ParentId FK and a virtual Parent navigation property. Parent ID#1 exists in the database:

using (var context = new TestDbContext())
{
    var newChild = new Child { Name = "Freddy", BirthDate = new DateTime(1999, 3, 3), ParentId = 1 };
    context.Children.Add(newChild);
    context.SaveChanges();
}

Now at this point after the SaveChanges, if you look at the Parent reference for newChild, it will be #null. Instead if you do this:

using (var context = new TestDbContext())
{
    var neverUsedParent = context.Parents.Single(x => x.ParentId == 1);

    var newChild = new Child { Name = "Freddy", BirthDate = new DateTime(1999, 3, 3), ParentId = 1 };
    context.Children.Add(newChild);
    context.SaveChanges();
}

In this example, after the save changes you will see that the Parent reference is present, even though we didn't associate it, we had still only set the ID.

When you have a long-lived DbContext, a difference in behavior when setting FK properties is bound to happen, and it can have really weird consequences that are revealed at runtime. If one of the EditorSettings had been previously loaded from the DB by that DbContext, creating a new record with that EditorSettingId would fill in the association, while another EditorSettingId would not. (Because the DbContext didn't know about it) That EditorSetting may have been loaded anywhere in the code prior to this call provided the same DbContext instance was used.

Even doing this:

using (var context = new TestDbContext())
{
    var newChild = new Child { Name = "Freddy", BirthDate = new DateTime(1999, 3, 3), ParentId = 1 };
    context.Children.Add(newChild);
    context.SaveChanges();

    // newChild.Parent == #null here....

    var neverUsedParent = context.Parents.Single(x => x.ParentId == 1);

    // newChild.Parent is available here!
}

In general it is better to avoid having both navigation properties and FKs mapped. I advise entities should use one or the other. When using navigation properties you can map FKs without properties using Shadow Properties in EF Core or Map.MapKey() in EF 6. For cases where I want to load/manipulate large amounts of data and don't need the related details I will use FKs with no navigation properties in those entities.

Answer 2

Couple of things come to mind why this might happen:

1. There was a change from lazy loading to eager loading in the context (see here), so after the first SaveChanges, accessing the EditorSettings property used to load it from the database.
2. An EditoSetting object with that specific id already existed in the database. This is not relevant if you create a new context in the method. Howeveryou mentioned it used to be in the controller, so maybe the something in the flow was changed.