![]() ![]() I opened an issue on Github asking if all of the above is intended behavior : I don’t think anyone expects an accidental load of an entity into the DbContext to suddenly change the behavior. Maybe I’m in the minority here, or maybe there is a really good reason for the restrict behavior acting as it does, but I really do think that for the majority of developers, when they use DeleteBehavior.Restrict, they are expecting the parent to be blocked from being deleted in any and all circumstances. SetNull sets null when it came, and restrict always stops you from deleting. I actually spent a long time using Google-Fu to try and find anyone talking about the differences between SetNull and Restrict but, many just go along with what I described in the intro. What About DeleteBehavior.SetNull?Īnother interesting thing to note is that the documentation for DeleteBehavior.SetNull is actually identical to that of Restrict :Īnd yet, in my testing, using SetNull does not depend on which entities are being tracked by the DbContext, and works the same every time (Although, I did consider that possibly this is a SQL Server function using the default value rather than EF Core doing the leg work). However, the point I’m trying to make is that if I have a nullable key, but I set the delete behavior to restrict, I should still see some sort of consistent behavior. ![]() If I set this to be a non-nullable key, then I will always get an exception because it cannot set the FK to null. ![]() Which is true, and does mean that I expect that a BlogImage entity *can* be an orphan. I’m sure some of you are ready to jump through your screens and tell me that this sort of ambiguity is because I am using a nullable FK on my BlogImage type. If by some chance you’ve already loaded the child entity (By accident or not), your delete restriction suddenly behaves completely differently. Still writing this, I’m struggling to understand the logic here. SqlException: The DELETE statement conflicted with the REFERENCE constraint “FK_BlogImages_BlogPosts_BlogPostId”. I *do* get the exception I was expecting all along : Given the documentation, the entity I pull back for deletion will not have the blog images themselves being tracked.Īnd sure enough given this code : var context = new M圜ontext() Ĭontext = new M圜ontext() // (blogPost.Id) So I used the following test script, which is exactly the same as before, except half way through I recreate the DB Context. This doesn’t really make that much sense IMO. If a property cannot be set to null because it is not a nullable type, then an exception will be thrown when SaveChanges() is called. This helps keep the graph of entities in a consistent state while they are being tracked, such that a fully consistent graph can then be written to the database. But why?!ĭiving headfirst into the documentation we can see that DeleteBehavior.Restrict has the following description :įor entities being tracked by the DbContext, the values of foreign key properties in dependent entities are set to null when the related principal is deleted. So instead of restricting the delete, EF Core has gone ahead and set the BlogPostId to be null, and essentially given me an orphaned record. When this code is run, and I check the database I end up with a BlogImage that looks like so : Var getBlogPost = context.Find(blogPost.Id) Ĭontext.SaveChanges() //Does this error here? We are deleting the blog post that has imagesĭo I receive an exception? The answer is. Let’s imagine I have a simple set of code that looks like do : var context = new M圜ontext() Then imagine the relationship in EF Core is set up like so : modelBuilder.Entity()Īny developer looking at this at first glance would say, if I delete a blog post that has images pointing to it, it should stop me from deleting the blog post itself. Let’s imagine that I have two models in my database, they look like so : class BlogPost
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |