Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EF 8 Migrations adds AlterColumn to every column, for subsequent migrations #34086

Closed
aplongh opened this issue Jun 25, 2024 · 2 comments
Closed
Labels
closed-no-further-action The issue is closed and no further action is planned. customer-reported

Comments

@aplongh
Copy link

aplongh commented Jun 25, 2024

I have an old application in .Net Core 3.1 and EF Core 3.1. I have succesfully migrated to .net 8 and EF Core 8. The migrations folder was HUGE, so I reset the migrations, deleting all records in the [__EFMigrationsHistory] table and deleted the migration folder (the migrations folder is in a separate project.

I succesfully ran the initial migration and EF created the class with all existing tables, columns, indexes, etc. As the Database already exists, I manually added the migrations record to the [__EFMigrationsHistory] table.

I then had to add a new table. When I ran the Add-Migration, the resulting class is HUGE (should have only contained the necesarry code for the new table). It includes code for (i think) every column in the database, such as the following:

            migrationBuilder.AlterColumn<Guid>(
                name: "TenantId",
                schema: "Common",
                table: "XrmOrganization",
                type: "uniqueidentifier",
                nullable: true,
                oldClrType: typeof(Guid),
                oldType: "uniqueidentifier",
                oldNullable: true)
                .Annotation("Relational:ColumnOrder", 300);

            migrationBuilder.AlterColumn<int>(
                name: "StatusCode",
                schema: "Common",
                table: "XrmOrganization",
                type: "int",
                nullable: true,
                oldClrType: typeof(int),
                oldType: "int",
                oldNullable: true)
                .Annotation("Relational:ColumnOrder", 211);

Any migration I try to add, adds these hundrends (maybe thousands) of line of code, altering the columns. As a remedy, I have manually deleted all these lines of code, but I would like to know the root cause and how to solve this issue, as the migrations file has more than 110 thousand lines.

Any help will be GREATLY appreaciated.

Include provider and version information

EF Core version: 8.0.6
Database provider: Microsoft.EntityFrameworkCore.SqlServer
Target framework: .net 8
Operating system: Windows 10 Pro
IDE: Visual Studio 2022 17.8.5

@aloksharma1
Copy link

aloksharma1 commented Jun 25, 2024

i think you are misunderstanding how model snapshot works in ef, as you said you have manually deleted all old migrations from previous version ef core cannot see it, the snapshot name in __EFMigrationsHistory is just the migration Id of previous migrations, so now that it cannot see those migrations (deleted code) it will treat whole model as a new database, now you have few options here to fix this issue:

  1. manually opt-out of migrations for the existing tables (mark it ignored using ModelBuilder.Ignore Method)

  2. let everything run once (whether you manually delete extra data/code you have to run atleast first migration for ef to make an actual snashot of existing database.

  3. iirc i saw somewhere here or some other git issue an incremental migration approach which you can use to divide your initial table migration in smaller code bases.

let me know how it goes.

@cincuranet
Copy link
Contributor

We currently don't have out-of-box support for squashing migrations. The work is tracked in #2174. This issue is in the Backlog milestone. This means that it is not planned for the next release (EF Core 9.0). We will re-assess the backlog following the this release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources. Make sure to vote (👍) for this issue if it is important to you.

However, with proper steps, you can do the squashing manually yourself. The steps are described here.

@cincuranet cincuranet added the closed-no-further-action The issue is closed and no further action is planned. label Jun 27, 2024
@cincuranet cincuranet closed this as not planned Won't fix, can't repro, duplicate, stale Jun 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-no-further-action The issue is closed and no further action is planned. customer-reported
Projects
None yet
Development

No branches or pull requests

3 participants