Why is there no update equivalent to WillCascadeOnDelete?

Question

When you're setting up a one:many relationship in EF code-first, you can choose whether it should cascade on delete like so:

modelBuilder.Entity<Assessment>()
    .HasRequired(asmt => asmt.CreatedByUser)
    .WithMany(usr => usr.Assessments)
    .HasForeignKey(asmt => asmt.CreatedByUserId)
    .WillCascadeOnDelete(true);

This translates to the SQL ON DELETE CASCADE part of a foreign key definition, ie.

ALTER TABLE [dbo].[Assessment]  WITH CHECK ADD  CONSTRAINT [FK_dbo.Assessment_dbo.User_CreatedById] FOREIGN KEY([CreatedById])
REFERENCES [dbo].[User] ([UserId])
ON DELETE CASCADE
GO

However, there doesn't seem to be a similar method in the Fluent API that allows you to control the value of ON UPDATE CASCADE, ie. something like .WillCascadeOnUpdate(). Why not?

score 2 · Answer 1 · answered Dec 04 '12 at 15:38

2

Entity framework work with relationship through navigation properties, so ON UPDATE CASCADE allready switched on for all such relations.

Hmm and on the other hand i'm not sure that you can directly change primary key of entity from Entity Framework.

answered Dec 04 '12 at 15:38

Kirill Bestemyanov

11,946
2
24
38

score 2 · Accepted Answer · answered Dec 08 '12 at 18:32

Well, apparently the answer to this is that you should never change the primary key in an ORM, even though DBMS's support the changing of the primary key. Because the assumption is that you will never change the primary key, there's no need for entity framework to allow you to specify whether to cascade on update, because the idea is that that primary key update will never happen.

Note, though, that this can still be done manually in most databases even if the entity framework ORM doesn't let you do it that way. The DBMS will just use its default behaviour for a cascade update if you do the primary key update, manually, directly in the database.

score 1 · Answer 3 · answered Dec 04 '12 at 23:47

1

You can't change the primary key.

That is a bad practice in general, but particularly when working with an ORM.

answered Dec 04 '12 at 23:47

Diego Mijelshon

52,548
16
116
154

What if the PK is a non-identity field, say a GUID? You could change it to another GUID... – Jez Dec 05 '12 at 00:08
Still wrong. The PK is supposed to be immutable. If it's changing, you chose the wrong field. – Diego Mijelshon Dec 05 '12 at 10:04
I refer you to [this answer](http://stackoverflow.com/a/1481524/178757). There are some times when you might need to change a primary key. – Jez Dec 05 '12 at 10:53
No, the problem occurs because a bad PK was chosen. The PK should NEVER have business meaning. Just because some databases support the ON UPDATE CASCADE concept doesn't mean it's a good idea. – Diego Mijelshon Dec 05 '12 at 12:21
It still doesn't mean you should use it. – Diego Mijelshon Dec 05 '12 at 13:28
But it does mean it's useful to be able to configure the behaviour just in case it is needed. – Jez Dec 05 '12 at 13:30
...Except ORMs don't work with that, because the POID is defined as immutable. – Diego Mijelshon Dec 05 '12 at 17:27
Where is it defined as immutable? – Jez Dec 07 '12 at 11:47
In the design and implementation of all mainstream ORMs. – Diego Mijelshon Dec 07 '12 at 14:42
So basically you're saying that if you want a system that uses (say) GUIDs for primary keys, and (either for legacy reasons or because maybe you need to sync with some other data source) you might sometimes need to update those GUIDs, you should just refrain from using an ORM? – Jez Dec 07 '12 at 15:40
Yes, that is correct. There are hacks (updating the Id with raw SQL and hope there are no threads anywhere reference the old entity), but no ORM I know allows modifying the key as part of the supported workflow. – Diego Mijelshon Dec 07 '12 at 15:45

Why is there no update equivalent to WillCascadeOnDelete?

3 Answers3

Linked

Related