Migrations: Allow access to IServiceProvider
See original GitHub issueCurrently (as of version 2.0) when a migration is created with a non-empty constructor the following exception is thrown during migration:
System.MissingMethodException: No parameterless constructor defined for this object.
Since ConfigureServices is already called during migrations and the ServiceProvider is used to resolve the DbContext it would be really nice if the same ServiceProvider could be used to resolve the constructor of migrations.
This would make it possible to inject other services and run them during the migration.
My use-case:
We use ElasticSearch as a search index on top of some of our ef model types. When the model scheme is changed, the search index scheme also has to be updated and sometimes data has to be reindexed.
Previously we simply used to Migration Id to check if the search index is at the same scheme as the database. If the search index migration id was not the same as the one in the database we simply recreated the index and reindexed all the data.
Recently our data grow to a size that this is no longer feasonable. It would take way too long. So we only want to update the search index during migrations that would affect the parts of the scheme that are indexed.
So what I wanted to do is call the (for example) reindex method from an ef migration, when the search index should be updated. For this I would need the inject the ElasticSearch client into the migration, which is not supported atm. Hence the feature request.
Issue Analytics
- State:
- Created 6 years ago
- Comments:8 (3 by maintainers)
We discussed this in triage and decided that we could make the service provider available to migrations via IInfrastructure. This unblocks people from doing advanced things while not promoting too much of a pit of failure.
@ajcvickers I can see that. Didn’t really think about the script generation feature, since we don’t use it,. But that is a good point.
What’s documented here provided a good base for me to implement my use-case anyway. Since
IMigrationsSqlGenerator
supports DI. The only thing that was really confusing for me is that I should replace the internal service provider, instead of providing an implementation ofIDesignTimeServies
, since I thoughIMigrationsSqlGenerator
was part of the design time service. But I had no previous experience with this part of EF, so that didn’t help.