Switching to Npgsql from SQL Server and using ForNpgsqlUseIdentityColumns() does not generate Identities

Using .Net Core 2.2.0 and Npgsql 2.2.0 . updated to 2.2

I started with using the SQL Server for EF Core. Then switched over to Npgsql and noticed that the primary keys are not being assigned as IDENTITY even after adding ForNpgsqlUseIdentityColumns(). When doing Add-Migration the generated Designer class does show the primary keys being assigned with ValueGeneratedOnAdd(). But after Update-Database the database does not have Identity columns nor any _seq tables. Script-Migration also generates a script without Identity columns

Link to Github repository where this occurs: Link

Steps to reproduce

• Created a new .NET Core MVC project following Microsofts guidelines
• Set it up with SQL Server -> add-migration, update-database.
• Switched over to npgsql -> Changed the DbContext to use Npgsql
• Added ForNpgsqlUseIdentityColumns() to OnModelCreating

public class BloggingContext : DbContext {
    public BloggingContext(DbContextOptions<BloggingContext> options)
        : base(options) { }

    protected override void OnModelCreating(ModelBuilder builder) {
        builder.ForNpgsqlUseIdentityColumns();
    }

    public DbSet<Blog> Blogs { get; set; }
    public DbSet<Post> Posts { get; set; }
}

• Ran Add-Migration, update-database. The generated Designer class did show adding ValueGeneratedOnAdd() for the Id columns
• Script-Migration generated a valid PostgreSQL script but without Identity Columns

Generated PostgreSQL script

CREATE TABLE IF NOT EXISTS "__EFMigrationsHistory" (
    "MigrationId" character varying(150) NOT NULL,
    "ProductVersion" character varying(32) NOT NULL,
    CONSTRAINT "PK___EFMigrationsHistory" PRIMARY KEY ("MigrationId")
);

CREATE TABLE "Blogs" (
    "BlogId" integer NOT NULL,
    "Url" text NULL,
    CONSTRAINT "PK_Blogs" PRIMARY KEY ("BlogId")
);

CREATE TABLE "Posts" (
    "PostId" integer NOT NULL,
    "Title" text NULL,
    "Content" text NULL,
    "BlogId" integer NOT NULL,
    CONSTRAINT "PK_Posts" PRIMARY KEY ("PostId"),
    CONSTRAINT "FK_Posts_Blogs_BlogId" FOREIGN KEY ("BlogId") REFERENCES "Blogs" ("BlogId") ON DELETE CASCADE
);

CREATE INDEX "IX_Posts_BlogId" ON "Posts" ("BlogId");

INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion")
VALUES ('20181208175929_Initialize', '2.1.4-rtm-31024');

INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion")
VALUES ('20181208181245_npgsql identity onmodelcreating override', '2.1.4-rtm-31024');

INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion")
VALUES ('20181208181418_postgresql database', '2.1.4-rtm-31024');

First time for opening an Issue on Github so if you need anything else or if the way I write the Issue can be improved then please let me know 😃.

[austindrenski]

Also the designer classes are not used for the migration in any way then? Since the changes are inflicted in there, but not in the migration script itself.

It depends. I believe the default for script generation is to create a complete script, though I think you should be able to supply some additional arguments that control the “from” and “to” of the migrations.

Glad to hear it’s working for you. I’ll go ahead and close this for now, but feel free to continue posting if you have further questions on this matter.

@roji may also have more information to add on the supported/not supported question (e.g. whether it’s on any of the roadmaps or been discussed and ruled out).

[austindrenski]

@stefanjm It looks like you’re attempting to apply an update that moves from a migration generated for SQL Server to one generated for PostgreSQL.

For example, this migration is empty, because nothing in your DbContext changed.

So the PostgreSQL-specific component that generates the migration script looks at these migrations and builds a script that 1) ignores any SqlServer:-prefixed annotations, and 2) applies these empty migrations generated after you switched providers.

Could you remove your SQL Server migrations, and then regenerate your migrations and script?

You may also be interested in the EF Core docs related to using migrations with multiple providers in the same project.

In general, I don’t believe that we support the use of migrations to migrate between providers, but I could be mistaken. @roji Could you weigh in?