locked
table per type inheritance RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    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?

     

    Joel

    Thursday, August 21, 2008 2:48 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    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...

     

    Noam

    Thursday, August 21, 2008 3:00 AM