英文:
How to restore databases migration
问题
我有一个mysql数据库，但我无法删除它。我在asp.net项目中丢失了我的迁移，并且在dbcontext文件中更改了一些内容。
当我尝试创建一个新的迁移并执行update-database时，它显示表'aspnetroles'已经存在。我应该怎么做？如何恢复迁移或如何使迁移与数据库相匹配？
英文:
I have a mysql database and I can not delete it. I lost my migrations in asp.net project and I changed some things in dbcontext files.
When I try make a new migration and update-database it says Table 'aspnetroles' already exists. What should I do? How can restore migration or how can ı equate the migration and database?
答案1
得分: 3
EF Core Migrations的dotnet ef database update将尝试将数据库更新到最新的迁移。它将查询__EFMigrationsHistory表，以查看哪些迁移已经应用，哪些仍然需要应用（如果有的话）。
对于某些问题的解决方法是通过手动插入迁移历史来模拟已经应用了更新，这样可以避免删除数据库，当然这可能在生产环境中会有问题。
像这样将记录插入到开发数据库中：
| MigrationId | ProductVersion |
|---|---|
| 20230516084711_Initial | 7.0.5 |
其中20230516084711_Initial是迁移文件的名称，去掉了.cs部分（或者是.Designer.cs中的[Migration("20230516084711_Initial")]属性中的值），而7.0.5是最初应用迁移时使用的EF工具的任意版本号。
对于需要模拟已应用的每个迁移，重复这个插入操作。然后你的database update将报告没有任何操作要执行。
当然，如果你没有真正应用的迁移中有关数据库的更改，这将会引发问题。请确保只对绝对已经完全应用的迁移执行此操作。
这也可以帮助"压缩"许多迁移。如果确保你的开发数据库（以及上下文和配置）与生产数据库保持最新和一致，你可以简单地删除所有（或者所有中间的）迁移，创建一个新的"Initial"（或单一的"Feature"）迁移，并在从迁移历史表中删除已删除的迁移的条目后，在生产环境中插入上述记录。
请注意，如果有多个开发人员拥有自己的开发数据库，这可能会导致问题；就像推送经过重整/压缩的全局Git历史一样，每个人都需要应用这些步骤来将他们的本地副本与新的现实同步。
英文:
EF Core Migrations' dotnet ef database update will try to update the database to the newest migration. It will query the __EFMigrationsHistory table to see which migrations are applied there and which ones still need applying, if any.
The resolution for some problems is to fake having applied an update by inserting the migration history manually. This prevents having to drop a database, which of course might be problematic on production.
Insert the records as they are applied to your development database, like:
| MigrationId | ProductVersion |
|---|---|
| 20230516084711_Initial | 7.0.5 |
Where 20230516084711_Initial is the name of the migration file minus the .cs part (or the value in the [Migration("20230516084711_Initial")] attribute in the .Designer.cs), and 7.0.5 is an arbitrary version number of the EF Tools used to originally apply the migration.
Repeat this insertion for every migration that you need to fake being applied. Then your database update will report that it has nothing to do.
This of course will cause problems if one of your migrations which you didn't really apply had changes with respect to the database. Make sure you only do this to migrations that definitely don't have changes, meaning: which have definitely been integrally applied.
<hr/>
This can also be helpful to "squash" many migrations. If you ensure that your development database (and context and configuration) are up-to-date and consistent with the production database, you can simply delete all (or all intermediate) migrations, create a new "Initial" (or single "Feature") migration, and insert the abovementioned record on production after removing the entries belonging to the removed migrations from the migration history table.
Do note this can prove to be problematic if you have multiple developers with their own development databases; just as with pushing a rebased/squashed global Git history, everyone needs to apply the steps to synchronize their local copy with the new reality.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论