Migrations: Is there a way to inline the CREATE INDEX statement in the CREATE TABLE statement?

Ask a question

Currently migration generates separate statements for create table and create index, even if they are in the same migration. Due to the relatively slow execution of index creation on the database we are using (about 5s per statement), this causes our automatic migration to take a long time. Is there a way to be able to inline the CREATE INDEX statement in the CREATE TABLE statement?

Include your code

Currently the migration will generate the following statement:

CREATE TABLE Accounts (
    Id bigint not null,
    Username varchar(255) not null,
    Password varchar(255) not null,
    Token varchar(255),
    PRIMARY KEY (Id)
);

CREATE UNIQUE INDEX IX_Accounts_Token ON Accounts (Token);

I expect to get:

CREATE TABLE Accounts (
    Id bigint not null,
    Username varchar(255) not null,
    Password varchar(255) not null,
    Token varchar(255),
    PRIMARY KEY (Id),
    INDEX UNIQUE (Token)
);

Include provider and version information

EF Core version: 6.0.8 Database provider: omelo.EntityFrameworkCore.MySql Target framework: NET 6.0 Operating system: Debian 11 IDE: Visual Studio 2022

[roji]

@buzzers we discussed this, and unfortunately the syntax where indexes are contained inside the CREATE TABLE is non-standard (e.g. no supported in SQLite); that’s why we didn’t implement this in the first place.

However, it shouldn’t be too hard to implement this outside of EF Core. You’d extend the Pomelo provider’s MigrationSqlGenerator and override the Generate method which accepts the list of MigrationOperations. At that point you can do what you want, i.e. look for all CreateIndexOperations corresponding to CreateTableOperations, merge those in, and override the appropriate SQL generation method to generate the DDL you want. You could represent the CreateIndexOperations as annotations on the CreateTableOperations, or possibly create an altogether new operation CreateTableWithIndexesOperation).

If this makes sense, you may want to check with @lauxjpn about including this in the Pomelo provider.

I’m going to go ahead and close this as we don’t intend to do this in EF itself, but feel free to continue posting here if you need guidance or have additional information.

[roji]

Thanks for the info, we’ll discuss and let you know. In the meantime you always have the option of using raw SQL in your migrations where this hurts the most.