Extending EF Core codegen - API Limitation?
I'm currently building a package, EFCore.ModelExtras to let EF track database triggers and functions and migrate them like any other relation.
To achieve this, I've extended a bunch of EF's migration generation classes, like
ICSharpMigrationOperationGenerator (Interface) (Base) (Mine). This works, and is all well and good for my current purposes, but I realize that this approach of extending the main EF generator, and replacing it in the DI container means that you can only pull this trick once. If someone wanted to use my package, but also use another package that offers a custom migrations generator of the same type I've overridden, they can't.
Are there any ways around this without 2 package authors collaborating (e.g. a shared base type or intermediary API), or might I be missing some way to achieve inter-package compatibility with the existing EF Core API?
Would this be something worth writing a proposal around?4 Replies
Unknown User•3w ago
Message Not Public
Sign In & Join Server To View
GitHub
Enable compositional approach of custom migration functionality · ...
Problem I just read this article : https://docs.microsoft.com/de-de/ef/core/managing-schemas/migrations/operations Reading the details about how to implement the generator objects for custom migrat...
@JP You have three options, manual decorator pattern, custom
MigrationOperation classes or some simple manual composition.
This has been in their backlog for years and no plans of changing it@chipsletten Ah, thanks for that link.
Depending on my motivation, maybe I'll look into actually doing that plugins system...
We shall see.
Posted, we'll see what they say!
https://github.com/dotnet/efcore/issues/17740#issuecomment-3530638151