1

OK, check out the following simple object model:

  • Entity ConcreteThingy derives from AbstractThingy.
  • Entity Owner can have at most 1 ConcreteThingy.
    • No two Owners can have the same ConcreteThingy.

EDMX:

enter image description here

DB model (TPT):

enter image description here

What I want:

I want 2 things, in descending order of priority:

  • Thing I want #1: Above all, I want the simplest, most concise, cleaner solution to #2 below.
  • Thing I want #2: When I delete an Owner, I want to automatically delete any potentially associated ConcreteThingy, along with the base AbstractThingy.

What I'm doing:

So, naturally, I went to the EDMX and simply turned on Cascade delete on the Owner 0 ↔ 0..1 ConcreteThingy association.

enter image description here

This works well in setting the Delete rule of the FK_ConcreteThingy_Owner relationship to Cascade, but I don't see ANY constraints/DB code that makes sure that the AbstractThingy record gets deleted as well.

enter image description here

Again, when I delete an Owner, the corresponding ConcreteThingy (if any) is deleted, but it leaves the dangling AbstractThingy, which not surprisingly, I don't want.

Can somebody please tell me what is the standard way to implement this type of tasks using EF 5?

I've tried by making AbstractThingy abstract, hoping that the SQL code would somehow infer what I want (understandably there would be some sort of chicken-and-egg conundrum for the generator, but hey, at least I tried it.)

Or should I define some sort of smart-ass referential constraint in my EDMX?

Or is it expected that I'd go to the DB and write code myself, like a trigger, etc...!?!? That would be a bit of a[nother] fiasco for EF and its design tools.

Thanks.

Fernando Espinosa
  • 4,625
  • 1
  • 30
  • 37
  • Can you reverse the 'abstract' and 'concrete' classes? Have abstract be FK'd to owner, and concrete FK'd to abstract? Then a series of cascading deletes will work. This also might help to normalize the 1:1 'abstract' to 'concrete' construction in this design. – user15741 Nov 19 '12 at 20:46
  • I know what you mean, but here's the tricky catch: **the design is intentionally that way.** This is the reason: http://stackoverflow.com/q/11270620/1426433 – Fernando Espinosa Nov 19 '12 at 21:47
  • 1
    Same problem here: http://stackoverflow.com/a/9071945/270591 That was for EF 4.x. I guess the situation didn't change with EF 5. – Slauma Nov 19 '12 at 22:01
  • @user15741: Write it as answer or comment to that question. I didn't ask it and the question owner doesn't notice your comment here. – Slauma Nov 19 '12 at 22:12
  • Sorry, saw the comment response and thought it was you. – user15741 Nov 20 '12 at 01:27
  • Possible duplicate with http://stackoverflow.com/questions/9064273/cascade-delete-in-entity-framework-table-per-type-inheritance. Btw. You could just replace association between Owner and ConcreteObject with association between Owner and AbstractObject (or perhaps create AbstractOwner that owns AbstractObject) – Sami Korhonen Nov 20 '12 at 22:50
  • It is indeed a question that one finds coming up but somewhat rarely: @Slauma mentioned that post as well (to the answer http://stackoverflow.com/a/9071945/1426433). I must insist that **the design is intentionally that way**; this example is a purposely artificial, but that was in order to keep it concise. You can look at a realistic example (and why the design is the way it is,) in http://stackoverflow.com/q/11270620/1426433. There, the conclusion was that I cannot really use base classes effectively due to a great awful lot of impedance mismatch between EF and the DB world. – Fernando Espinosa Nov 21 '12 at 17:58

0 Answers0