Add partial methods to the scaffolded DbContext code

[cbrianball]

To use some of the new features in EF 2.1 (such as DbQuery<> to map to a view), the model needs to be configured; however, I don't see a way to configure the model outside of OnModelBuilding from the generated DbContext class. I don't want to modify the file as I regenerate it whenever I make changes to my database schema.

Is there a supported way to further configure the model without having to modify generated code?

Further technical details

EF Core version: 2.1
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows 10
IDE: VS 2017

[ErikEJ]

The latest version of EF Core Power Tools adds a partial OnModelCreating method, that you can add in a partial DbContext class.

[ErikEJ]

See ErikEJ/EFCorePowerTools#20 (comment)

[cbrianball]

@ErikEJ
I didn't even know that tool existed, awesome! With one small exception (listed below) it works great. I especially love the fact that I can generate my classes from a SQL project rather than having to publish my SQL project, then reverse engineer.

One hiccup I see is that one of my tables has a calculated column, and that column is not included in either the POCO or the ModelBuilder. I can add it back in manually (now that there's a partial), so I have a work-around for now. Is this a known issue?

[ErikEJ]

@cbrianball Are you generating from a dacpac or a SQL instance? With dacpac I am unable to scaffold computed column information, it is only available from a live LocalDB / SQL Server instance...

[cbrianball]

I am using a dacpac (more specifically I'm referencing the Database project, but I assume the tool is analyzing the dacpac that is produced by the project).

The computed column is defined in my SQL Database project. Even then, you aren't able to scaffold computed columns? I know very little of the inner workings of EF Core and dacpacs, so I can't speak intelligently on the subject, but I feel the information should be there since the dacpac creates the computed column when it's published.

I'll point the power tools to my LocalDB today and let you know if that solves the issue with the missing computed column.

Also, when using the Power Tools, there's a navigation property missing (but again, I can add it back using the partial method as a work-around). It happens with Scaffold-DbContext as well (I've reported it as issue #11936). I'm guessing it will be fixed in both places when the bug is fixed and released.

[ErikEJ]

I assume the tool is analyzing the dacpac that is produced by the project).

Correct!

The dacpac has no information about the data type of the computed column, so I am unable to scaffold it from the dacpac.

[cbrianball]

That makes sense (I now realize that when you create a computed column, you don't actually declare the data type).

I ran the tool pointing to my local database instance and it does work as you said it would. Thanks for all your help (and quick responses)!

[ErikEJ]

@bricelam Would there be interest in this in the product? ErikEJ/EFCorePowerTools#20 (comment) ?

[bricelam]

I've considered it in the past, it just falls apart with "update model from database"--we won't be able to tell which parts of the model were configured where. In our most recently discussed design, this means that every time you update the model, all of the OnModelCreating code (no matter where it came from) would be re-scaffolded into the main OnModelCreating body causing duplication and possibly errors.

[ErikEJ]

Ok, I will keep it for now, and support re-scaffolding with Power Tools (I save selected tables and options after each "run")

[cbrianball]

I'm at a lost as to the conversation that's happened since I closed this issue. Is the intent of Scaffold-DbContext to be a one-time use to reverse engineer a database (and moving forward, for edits to be made by hand)?

If that's the case, I would strongly urge the team to consider the use-case of database-first development. I know code-first is popular, but many developers I work with agree that database-first is preferred, and we have used tools such as Scaffold-DbContext (and now EF Core Power Tools) as well as the reverse POCO generator for EntityFramework to generate the code based on the database schema.

If this isn't the point of this conversation, then I apologize for not following the conversation.

[ErikEJ]

The intention of reverse engineering in EF Core Power Tools is to continuously reverse engineer and re-generate the code, by taking advantage of partial classes..

[bricelam]

#831 is about a more intelligent workflow that preserves things like navigation renames and type hierarchies.

[ajcvickers]

Putting this on the backlog to track adding partial methods in general. We should consider whether adding an OnModelCreating partial makes sense now, even if we then have to deal with it in some way if/when update model from database is implement.

[ajcvickers]

Merged, but we may want to discuss in a design meeting.