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

Migration not doing anything for change of varchar length #31

Open
jeffbromberger opened this issue Nov 17, 2016 · 5 comments
Open

Migration not doing anything for change of varchar length #31

jeffbromberger opened this issue Nov 17, 2016 · 5 comments

Comments

@jeffbromberger
Copy link

I had a property which was a "string" and this of course created a varchar(255) in MySQL. After realizing that I needed more space, I added the following fluent:

        modelBuilder.Entity<TableName>()
            .Property(a => a.FieldName)
            .IsRequired(true)
            .HasColumnType("varchar(1024)");

Then I ran add-migration and saw that it generated this:

       migrationBuilder.AlterColumn<string>(
            name: "FieldName",
            table: "TableName",
            type: "varchar(1024)",
            nullable: false);

However, when I run update-database, nothing changes in MySQL. I repeated all the steps and logged all the queries and there is only this one:

    INSERT INTO `__EFMigrationsHistory` (`MigrationId`, `ProductVersion`)
    VALUES ('20161117191356_mig3', '1.0.1')

No alter query seems to be generated...

@SapientGuardian
Copy link
Owner

That's odd. I was able to reproduce this, and confirmed that the alter statement is being generated by our EF provider, but not getting sent to the server. I added this silly select 1 to my migration, like so:

            migrationBuilder.AlterColumn<string>(
           name: "TestField",
           table: "Client",
           type: "varchar(1024)",
           nullable: false);

            migrationBuilder.Sql("select 1");

And that caused the alter column command to be sent to the DB. @how02 do you think this is our bug, or something upstream? I didn't see any sort of explicit "commit" type operation for any of the other ops.

@nezbo
Copy link

nezbo commented Jan 18, 2017

+1 for this. I noticed the problem with a property like this:
[Column(TypeName = "text")] public string ResponseBody { get; set; }
The property doesn't get respected by the entity framework (not your bug I guess), but when I set the type manually in the fluent api (inside OnModelCreating):
builder.Entity<TransactionLog>().Property(l => l.ResponseBody).HasColumnType("text");

and did a Add-Migration it created the following:
migrationBuilder.AlterColumn<string>( name: "ResponseBody", table: "TransactionLog", type: "text", nullable: true, oldClrType: typeof(string), oldNullable: true);

but did not have an effect when applying Update-Database. If I delete all migrations and create a new one the tables are created properly (still not by respecting the property, but due to the fluent api commands).

@pingvinen
Copy link

I am experiencing exactly the same. The migration itself looks fine with the AlterColumn statement, but no queries are sent to the server.

+1

@budda2
Copy link

budda2 commented Oct 23, 2020

+1

@SapientGuardian
Copy link
Owner

This library hasn't been maintained for years. I would suggest using one of the providers on this page: https://docs.microsoft.com/en-us/ef/core/providers/?tabs=dotnet-core-cli

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants