實體框架遷移變更檢測

Question

最近，我一直在研究EF遷移的工作方式，遇到了一個我無法真正理解的問題。

我讀這文章，這是我看到：

在此階段，開發人員＃2可以運行Update-Database，它將檢測新的AddRating遷移（尚未應用於開發人員2的數據庫）並應用它。 現在，“評級”列已添加到“博客”表中，並且數據庫與模型同步。

我無法獲得的是EF如何確定它必須應用AddRatings遷移中的更改。 據我所知，工作流程如下：

1. 假設我們在項目中有兩個遷移（ID為4和5）尚未應用到數據庫（例如，我們獲得了應用了1、2和3遷移的舊版數據庫）。
2. 運行更新Db命令。
3. EF轉到數據庫，查找MigrationHistory表並獲取最新的遷移。 然后，EF看到項目中存在遷移4和5，並且由於數據庫中的最新遷移為3，因此適用4和5。

但是，當我看這篇文章的屏幕時，我並沒有真正理解它。 這是我期望的結果：

1. Dev 2數據庫中存在遷移First，AddUrl和AddReaders。
2. EF在數據庫中查找最新的遷移-這是AddReaders。
3. 項目中的最新遷移也是AddReaders。
4. 因此，根本不需要應用任何更改。

有一個問題，即代碼模型和最新的遷移模型並不相同，但是EF可以通過對數據庫的更改進行修改，盡管會產生警告，如文章所述。

問題是，我在推理中出了什么問題，以及EF如何理解，即使數據庫和代碼中的最新遷移是相同的 ，也必須應用另一種遷移。

而且，據我所知，MigrationHistory中的壓縮模型僅在運行Add-Migration命令時起作用，而與Update-Database命令無關。 是這樣嗎？

Answer 1

執行更新時，EF將程序集的遷移集與數據庫的遷移集進行比較，並將所有缺少的遷移都應用於數據庫。 丟失的遷移是在歷史記錄列表的末尾還是中間的某個位置都沒有關系。

遷移是通過比較MigrationId所以你是對的，壓縮的模式無關與Update_Database命令。