Add ExcludeFromMigrations option

[visionarycoder]

Feature Request:

Enable use of "ExcludeFromMigrations()".

A sample of the output code is shown below. For full support, I think it would need to be in the GUI as a checkbox on the Advanced options.

Code

The output would look like this:

modelBuilder.Entity<MyTable>(entity =>
        {
            ...
            entity.ToTable("MyTable", e => e.ExcludeFromMigrations());
            ...
         }

Background

In my client's environment only allows migrations in the dev environment. When EFCore projects are migrated to other platforms where migrations are not allowed, we're seeing errors where the [dbo].[__ConversionHistory] does not exist. The "ExcludeFromMigrations()" helps eliminate the error, while allowing test scenarios to create a DB as needed. E.G.: SQLite In-memory db.

[ErikEJ]

You can add that on a partial DbContext class with the OnModelCreatingPartial method

[visionarycoder]

I'm asking if a checkbox could be added to the UI to make it easier to enable.

[ErikEJ]

Got it, but mixing migrations and db first is very uncommon, and you are the first and only person asking for this. And there is a simple way to do this in your own code.

[visionarycoder]

My client has 934 tables in one database. 51 databases on a single cluster. Yeah... It's a lot of manual work to add that flag. I will keep digging to better understand how your tool works.

[ErikEJ]

I still do not understand why you need that flag. Why not just exclude the table all together?

[visionarycoder]

It's a mess. There are process, database design, and implementation challenges with my client.

Developers can create tables in the development db environment. Reverse engineering works in this scenario. When we move to other db environments, all db changes are managed through a dacpac. Any db-first code will have issues if it tries to check the existing schema aka query the __ConversionHistory table. That table __ConversionHistory does not exist in the non-dev environments. The failed read throws an exception which is buried deep in the EF internals.

In one scenario, my client used a db-first approach for their OAuth implementation. Out of 50 developers, I was the only one that recognized the reported exception was tied to a db-first approach. Keep in mind, this code had been in production for over 4 years. (Long story.) When they added DynaTrace to their production environment, the exception was the #1 error on the system.

When developers reverse engineer the existing database, they can make changes in the dev db context. Each execution will include a call to the __ConversionHistory table under the covers. No problem. In dev, that's fine because the table exists. The developers think everything is fine. They check in their code and errors start appearing in Test, Staging, and Prod. Especially in Prod. (See above)

If I can add the ExcludeFromHistory option in the code, I can avoid the issues related to non-dev db environments while still being able to create the first instance of the database for... Testing! If I want my team to build an in-memory db for unit tests or integration tests, having the code to create all of the required tables.

The product catalog is a mess. There are PK/FK linkages in places where you'd never expect AND they are missing PKs on some critical tables. It is a huge mess. I am working on the data models but it will take time. Possible years to get the ball of mud into a better place. Documentation is spotty. Another long story.

So I'm caught between the two extremes. I need to create a database with table definitions for unit testing on the far left of my CI/CD pipeline. I cannot allow migrations in production, far to the right of the pipeline. I'm not going to add the required call to 900+ table definitions. It would get overwritten the next time the models are updated through your UI.

And that's how I got to the request. I understand it seems weird and useless, but it is all about context.

[ErikEJ]

@visionarycoder Hmmm... Any new feature I add will cost me time and support, and if only one person in the world is asking for it and there is a simple workaround, unless you pay me a lot of money I am not going to do it.

I do not understand why you cannot simply exclude the offending table from your DB first configuration with EF Core Power Tools. In addtioion, Power Tools can even generate code from a .dacpac intstead of a live database.

If you give me a one time sponsorship I will be happy to discuss the options with you in a call 😄

[ErikEJ]

Also, EF Core Power Tools cannot fix bad processes, that is something you as a team will have to address.

[visionarycoder]

I know you can't fix process issues with technology. This is a long-running task of mine.

I need to better understand your code. It's more a question of time for me. If I can figure it out, I can add a PR then we'd both be happy.

As for a single use-case, I don't fully agree. I have worked with several clients/employers that are very permissive in the dev environment and very restrictive in the production environment. I can't be the only one to have seen this scenario in the real world. I might be the first to raise it with you but... shrug.

Thanks for answering my questions. As I said, I need to learn more about your code to be more articulate and/or create a PR for your review. Thanks again.