I believe your problems are traceable to the fact that your mapping table BusUnitDimension
has its own primary key, Id
, as opposed to the more typical approach in which the BusUnitId
and DimensionId
FK properties together comprise the compound primary key of BusUnitDimension
.
Observe that
OrderDetails
in Northwind and theHeroPoweMap
in the Breeze many-to-many example have compound keys.
Your choice creates complications.
First, it becomes possible to create multiple BusUnitDimension
entities representing the same association between BusUnit
and Dimension
(i.e., they all have the same pair of FKs). The database may be able to prevent this (it's been a long time since I looked) but whether it does or doesn't, it won't prevent you from creating those duplicates in Breeze ... and maybe not in EF either.
Secondly, it opens you up to the problem you're currently facing. If those mapping entities are in the DbContext
when you perform the delete, EF may (apparently does) try to null their FK properties as it sets either BusUnit
or Dimension
to the deleted state.
You can get around this, as has been suggested, by making both the BusUnitId
and DimensionId
FK properties nullable. But that is contrary to the semantics as a BusUnitDimension
must link a real BusUnit
to a real Dimension
; they aren't optional. The practical consequence may be that you don't get cascade delete from the EF perspective if you do this (not sure if the DB will enforce that either). That means you'd have orphaned BusUnitDimension
rows in your database with one or both FKs being null. I speculate because I'm not used to getting into this kind of trouble.
Another approach would be to set their FK values to zero (I think Breeze does this for you). Of course this implies the existence of BusUnit
and Dimension
table rows with Id == 0
, if only during the delete operation.
Btw, you could actually have such "sentinel entities" in your DB.
You must make sure that these BusUnitDimension
are in the deleted state or EF (and the DB) will either reject them (referential integrity constraint) or orphan them (you'll have BusUnitDimension
rows in your database with one or both FKs being zero).
Alternatively, if you know that the DB will cascade delete them, you can simply remove them from the DbContext
(remove from the EntityInfoMap
in the EFContextProvider
). But now you have to tell the Breeze client to get rid of them too if it happens to have them hanging around.
Enough Already!
These wandering thoughts should tell you that you've got yourself in a jam here with way too much bookkeeping ... and all because you gave BusUnitDimension
its own Id
primary key.
It gets a lot easier if you give BusUnitDimension
the compound key, {BusUnitId
, DimensionId
}. You must also give it a payload property (anything will do) to prevent EF from hiding it in its "many-to-many" implementation because Breeze doesn't handle that. Adding any nonsense property will do the trick.
HTH