Entity Framework 4 Table Per Hierarchy - How To Define Navigational Properties On Children?

Question

I currently have a Entity Framework 4.0 model in place with Table Per Type (TPT), but there are a few performance issues (lots of LOJ\'s/CASE statements), as well as an issue ma

Answer 1

So i solved a few of my issues, but i hit a brick wall.

First of all, when you create self-referencing FK's in the database side, when you try and "Update Model from Database", Entity Framework will add these navigational properties to the main base type, as it has no explicit sense of TPH - you need to do this in the model side.

BUT, you can manually add the navigational properties to the child types.

WRT this error:

Error 3032: Problem in mapping fragments starting at lines 373, 382:Condition members 'Locations.StateLocationId' have duplicate condition values.

That was because i had an FK called "Location_State" which i was attempting to use for the "ZipCode_State" relationship, AND the "City_State" relationship - which does not work (still no idea why).

So to solve that, i had to add extra columns and extra FK's - one called "ZipCode_State", and another called "City_State" - obviously it has to be a 1-1 between navs and physical FK's.

Location.LocationType has no default value and is not nullable. A column value is required to store entity data.

That is my discriminator field. In the database side, it is not nullable.

I read threads about this issue, and they said you need to change the relationships from 0..* to 1..* - but my relationships already were 1..*.

If you look at my "Locations" actual database table above, all the FK's are nullable (they have to be). Therefore i started wondering if my relationships should be 0..*.

But they are nullable because of the TPH - not all "Locations" will have a "State". But if that Location is a "City", then it HAS to have a "State".

My feelings were further comforted by this SO question: ADO EF - Errors Mapping Associations between Derived Types in TPH

I was actually trying that workaround (before i even came across it), and the workaround does not work for me. I even tried changing all the relationships from 1..* to 0..*, and still no luck.

Wasting too much time here, I've gone back to TPT.

At the end of the day, with TPH i would have had a ridiculously large table, with lots and lots of redundant, nullable columns. JOIN-wise, it's more efficient. But at least with TPT i am not required to have nullable and self-referencing FK's.

If anyone has a solution to this problem, let me know. But until then, im sticking with TPT.