Re: EF Designer ignores my foreign key

Adrian T. wrote:
I managed to find what went wrong. I did some searches in the edmx
file and finally I found this message: "warning 6030: The relationship
'FK_Items_ItemGroupId' uses the set of foreign keys '{CompanyId,
ItemGroupId}' that are partially contained in the set of primary keys
'{CompanyId, ItemId}' of the table 'Items'. The set of foreign keys
must be fully contained in the set of primary keys, or fully not
contained in the set of primary keys to be mapped to a model." This is
just wrong (please notice I didn't use the word crap). I was very
enthusiastic about EF but my faith is getting weaker each day.
The scenario I explained is very common. In fact, you will hit this
whenever you need to create a database that contains multicompany
data.

At first I thought: they're right, because what you're doing is creating a m:n relationship between two tables. However, your link below to Andres' post cleared it up as his tables clearly show that this is a scenario which should work properly.

> After I found the warning message in the edmx file I did some
searches on that and I found out that there are other people that
posted information about this a long time ago. Please see
https://forums.microsoft.com/Forums/ShowPost.aspx?PostID=3186392&SiteID=1.
The problem this guy has is identical with mine. Because he has a
multicompany database, the CompanyId field is part of most primary
keys in the database. I would just like to hear somebody say that
there are at least plans to make this a supported scenario. Otherwise,
EF has no chance of becoming a serious candidate to use even in medium-
sized projects.

(Btw, Andres was the former lead developer of DeKlarit, so he definitely knows what he's talking about and what an O/R mapper does, it's strange that the EF team didn't take his remarks more seriously, as it's been almost a year since he posted that.)

I don't know why the EF team didn't fix this, and I can only describe from my own experience with reverse engineering an entity model from a relational schema, but as I do recall we had a similar bug very early on in LLBLGen Pro as well (I clearly see this as a bug) and I think it was even in the first beta cycle of v1. The thing is this:
the PK side in Supplier is: CompanyID*, SupplierID*. The FK side in product is: CompanyID*, SupplierID. Both sides have a PK field, CompanyID. You can now conclude two things:
1) it's a 1:1 relationship but there's an error: SupplierID isn't in the PK to make it a true 1;1 relationship
OR
2) it's an m:1 relationship (which is the correct conclusion).

In theory, you can say: the first conclusion (which apparently is what MS chose to do) is legit. However, in the case that the model is reverse engineered, so the FK is correct. So conclusion 1) can't be legit in practise, because otherwise the FK wouldn't be correct. In the case of reverse engineering the model of course :)

So in this case, the logic which detects the relationship type can't decide it's an error, it's a m:1 relationship, and this is then simple to detect: the FK side doesn't form the PK of the fk side table (product).

Now, can they always detect if the model is reverse engineered, or better: that the store model is indeed read from a db? Well, unless they store that information (which they don't), you can't: someone could have written the store XML meta data by hand and could have made an error.

I think, the core mistake is that they don't store all the data which they read from a db as 'data from a db schema', or at least make it detectable that the store meta data is indeed read from a relational schema and not written by hand. That way, you can simply conclude: what's in a relational schema is correct, and should be followed as-is.

After all: by reverse engineering from a relational schema, the store meta data follows from the relational schema in the database. By model-first it follows from the entity definitions + mappings.

But of course, I can only guess. Perhaps they simply didn't see it as that important, however to me it looks like a fix with 1 line of code... Yes, the EDM is much more than 'just an ORM'. :) Funny that the basic ORM stuff isn't even in place.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
.

Relevant Pages

  • Re: Buying Keys from Blizzard?
    ... Battlechest which has up to BC and another $40 for WotLK. ... point I can justify passing the store for the deal but if Blizz is ... DVD keys or buy the DVD keys from Blizzard. ...
    (alt.games.warcraft)
  • Re: Buying Keys from Blizzard?
    ... Battlechest which has up to BC and another $40 for WotLK. ... point I can justify passing the store for the deal but if Blizz is ... IIRC Blizzard charges the same as Gamestop, ... DVD keys or buy the DVD keys from Blizzard. ...
    (alt.games.warcraft)
  • Re: Where does your APL application hold its settings?
    ... the accepted practices call for on other Unix variants. ... If you are going to "avoid platform specific facilities" then you're going ... The keys are easy to find and to ... store a file name than to store a copy of a file. ...
    (comp.lang.apl)
  • Re: In 2006, 99.8% of burglars were unable to open or remove a gun safe.
    ... and/or keys. ... where are your facts that "most burglaries are inside jobs" Anyway, ... out of the cash register and put it in their pocket - that way the cash ... store owner will do it to write it off on his taxes. ...
    (misc.survivalism)
Quantcast