#1  An application cannot change the primary key (PK) of an existing(already saved) entity.

It makes no difference whetherthe PK is composite or single valued … you just can’t do it.

My recollection is that EFprohibits changes to the PK but I’m not certain. We do know that allowing achange to the PK invites numerous unfortunate consequences when the PK of thechanged entity is the foreign key of other, child entities.  Consider theeffect on Order-Line-items of changing the ID of its parent Order. The databasecould detect a FK violation and throw an exception; it might not in which caseyou’ve orphaned the child line items.

We agree that DF does notproperly report the error when the application tries to change the PK

DFdefect #1: We should throw a clear exception when you try to save an updatedentity with a pending change to the PK. Instead, the save appears to succeedalthough it did not.

DFdefect #2: We do throw an exception if you try to save an updated entity with apending change to the PK and at least one other property. Unfortunately, (a) werely on the server to produce the exception when we could detect it on theclient and (b) the wording of the exception is not clear about the cause or theresolution.

We will correct these defects inour next release. But our no-PK-change rule is a deliberate choice in DF; wefeel the defects are in the reporting, not in the prohibition itself.

What to do?

All architects agree that oneshould never change the primary key of an existing entity. That said, we knowthat it happens, especially with legacy databases in which the key contains ameaningful value … such as some portion of an entity’s “name”.

If the app must be able tochange the entity PK, the only permitted way to do that is

                 ·       copy the entity,

                 ·       give it the revisedPK,

                 ·       delete the original.

You can do this all in the sameEntityManager and submit these changes in the same save (so they are committedin the same transaction).

This insert+delete approach isopen to the same risks as I mentioned above: potential FK violations andorphaned children. But at least you had to work at “doing the wrong thing”.