SapientGuardian / SapientGuardian.EntityFrameworkCore.MySql

MySQL database provider for Entity Framework Core
53 stars 9 forks source link

Migration not doing anything for change of varchar length #31

Open jeffbromberger opened 7 years ago

jeffbromberger commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

+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 commented 7 years ago

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 commented 3 years ago

+1

SapientGuardian commented 3 years ago

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