意見，實體，無法推斷主鍵

我做了一個看法，所以我的網站的後手更加連貫。然後我試圖將其映射到我的實體架構。意見，實體，無法推斷主鍵

我有消息：

沒有定義主鍵，不能推導出一個主鍵，表排除

所以我做了一個！通過組合3列，我確定它是獨一無二的。我稱之爲新的專欄「id」。

實體這麼想的，似乎與我的「ID」的獨特方面同意，因爲該錯誤信息不會消失，我不能導入我的看法......

來源

2016-09-30 Antoine Pelletier

好吧，我不得不使用sql函數ISNULL（id，）在我的「id」clolumn上，使它成爲一個非空值，因此Entity明白它永遠不會爲null，因此，將它檢測爲潛在主鍵

來源

2016-09-30 17:03:11

這不是EF的工作。在代碼第一次約定之後，「id」應該是關鍵字，如果不是，則應該使用數據註釋或流暢API將其聲明爲關鍵字。但是，當你必須使用sql時，這會建議使用DB第一種方法。在那裏，EVERY表必須有一個NOT NULL PK列組合，所以如果元數據中出現錯誤，EF可能預期模型不正確（它不能使用元數據重新創建表）並排除它。 – DevilSuichiro

我使用db第一種方法是的，但你看，通常我以某種方式結束與我的意見內的唯一領域（主鍵）。在這種情況下，我甚至不需要指定女巫專欄是一個潛在的主鍵，Entity爲我完成這項工作，並決定女巫組合將代表視圖中最好的主鍵，但這次我沒有任何不是null）唯一值，所以我創建了一個並指定它不能爲空......我知道這很奇怪，但它的工作 –

EF將知道任何名爲「Id」或TypeName（+'_'）+「Id」的屬性是要創建的屬性的PK，如果不是這種情況你不得不指定它，我不認爲它會識別任何其他組合，因爲它不知道哪些屬性是所有行的唯一標識符。如果您先執行代碼，則可以將不可爲空的屬性（可映射到單列）的任意組合並將它們指定爲使用數據註釋/流利API的鍵。 – DevilSuichiro

意見，實體，無法推斷主鍵

回答

相關問題