table per type inheritance RRS feed

  • Question

  • This was covered in another post but I would like some verification because I won't be able to use EF if what I've read is correct.


    I'm having a problem getting table per type inheritance to work.  I'm using a textbook example like the following where an employee "is" a person:


    person, Columns: person_id (PK)(IDENTITY), name

    employee: Columns: person_id (PK), department


    The above works fine, however, most of my subtype tables are like this instead:


    employee, Columns: employee_id (PK)(IDENTITY), person_id (FK), department


    When I try to generate a model using the later table structure, I get:


    Error 1 Error 3025: Problem in Mapping Fragment starting at line 60: Must specify mapping for all key properties (employee.employee_id) of table employee.
     C:\Documents and Settings\joel\My Documents\Visual Studio 2008\Projects\Person\Person\PersonModel.edmx 61 15 Person


    A previous poster said the base-subtype tables must be related PK-PK.  Ours would be PK-FK.

    One of the main reasons I want to use EF over Linq to SQL is because EF handles this inheritance.  That would greatly simplify our coding.  Are there any workarounds?  When will this be fixed/improved?



    Thursday, August 21, 2008 2:48 AM


  • The above schema is not supported for standard TPT mapping: It does not enforce the existence of a single employee instance for a single person instance.


    I can think of two workarounds. The first is tricksy: In the SSDL, you could tell the EF that they key of the employee table was actually the person_id column. You could also tell it that the employee_id column has StoreGeneratedPattern="computed" (I think that's the correct value...)


    A second, safer workaround would be to create a view of the employee table that omits the employee_id altogether, and use sprocs to do the CUD work against the view. You'll then need to use sprocs for your whole hierarchy...and essentially lose a lot of the value of the EF.


    The schema, though, seems unsafe for use with TPT, and I don't really like either solution above much, so were I in your shoes, I would either change the schema or use an ORM that doesn't make the kind of round-tripping data integrity guarantees that the EF does.

     Perhaps someone can come up with a better solution, though...



    Thursday, August 21, 2008 3:00 AM