Open roji opened 5 years ago
Possibly covered by #24710
This can also be used for seeding.
The callback will be executed in a transaction, and it needs to be idempotent.
This was the proposed API for providers and extensions:
public interface IMigratorPlugin
{
void Migrated(DbContext context, IMigratorData data);
Task MigratedAsync(DbContext context, IMigratorData data, CancellationToken cancellationToken = default(CancellationToken));
void Migrating(DbContext context, IMigratorData data);
Task MigratingAsync(DbContext context, IMigratorData data, CancellationToken cancellationToken = default(CancellationToken));
}
public interface IMigratorData
{
IReadOnlyList<Migration> AppliedMigrations { get; }
IReadOnlyList<Migration> RevertedMigrations { get; }
Migration TargetMigration { get; }
}
However, we decided to revisit this when we have a better understanding of the provider and extension scenarios that this will enable.
Note: this is needed in order to fix #33279
Original issue: https://github.com/npgsql/Npgsql.EntityFrameworkCore.PostgreSQL/issues/292
tl;dr PostgreSQL has extensions, which can be added via the regular migration process. However, since extensions can add database types, the ADO layer must be instructed to reload types.
EFCore.PG does this if the migration is applied when first creating a database, since RelationalDatabaseCreator is public. However, for users applying migrations programmatically (
context.Database.Migrate()
) this would currently require extending Migrator, which is an internal type.This is a non-critical issue - users can work around it by triggering type reloading themselves. Npgsql can also extend Migrator for now even though it's internal.