Reverse Engineer: Better support for namespaces

[roji]

Table schemas don't appear to make it into scaffolded entity code in any way; If I have two tables named Users in schemas A and B, the reverse engineering process will simply created Users and Users1 inside the reverse-engineering namespace. This don't seem to be a very satisfactory result.

I think the expected result is probably to map non-default database schemas (i.e. non-dbo in SqlServer) to namespace underneath the reveng namespace. So, assuming we're reverse-engineering to namespace Models, dbo.Users would get scaffolded to Users.cs, while schema2.Users would get scaffolded to Models.Schema2.Users.

[lajones]

You should get either the [Table] attribute on the POCO class or the equivalent fluent API ToTable() in the context OnModelCreating() method saying what the underlying schema/table name are. Please let me know if you're not seeing this.

I know we've discussed before having the schema in the namespace and decided not to. I'm not sure if this was just to stay consistent with what EF6 did or whether there are other reasons. @rowanmiller do you remember?

[rowanmiller]

We should re-discuss this, it was one of the biggest complaints about reverse engineer in EF6.

[rowanmiller]

Discussed and agreed that this would be good. We could detect if you have multiple schemas and start doing sub-folders/sub-namespaces automatically... or we could just have a flag that you supply.

For the moment, we are just ok with the trivial algorithm we have. If we require the flag when we implement this, then we should write a warning telling folks about the flag.

[lajones]

Note: the "DB schema translates to C# namespace" suggestion was also made as part of #3861 (and many other places I'm sure).

[connde]

Hope this get developed soon :) It will make it lot easier when generating contexts with different schemas.

[olavorn]

@rowanmiller Hi,

In addition to @roji's, another (more general I guess) aproach also making use of a parameter -ContextNamespace, cause even if they may be stored in subfolders, it would be usefull to override the default namespace in the command for general purposes. Ex:

I want to scaffold all tables into Model\Design : This makes much sense, since I want to keep Model root folder to adaptations and extensions to the scaffolded Model (wich EF also suggests by design while defining classes as partial).

Scaffold-DbContext (...) -OutputDir Model\Design will generate on namespace <project>.Models.Design. ...Too Bad :(

the goal is not only to have a parameter we can use to place the files into a folder (-OutputDir), but also another parameter to define the context namespace. In this case:

Scaffold-DbContext (...) -OutputDir Model\Design -ContextNamespace <project>.Models...

This would output in Models\Design files with namespace '.Models'.

@roji's scenario would be accomplished with something like this:

Scaffold-DbContext (...) -OutputDir Model\Schema -Schema <schema> -ContextNamespace <project>.Model.<schema> in the core, iterating thru the schemas ....

[roji]

@olavorn your suggestion seems like a separate issue - allowing users to control the namespace separately from the OutputDir isn't the same as asking for schemas to be automatically translated into C# namespaces (even if it your feature proposal would provide a clunky manual workaround). I'd open a separate issue on this.

[olavorn]

@roji I agree with you, but before that, seems to me a good idea to exaust this a little bit here; As for the clunky workaround, the last example I put was more like an implementation suggestion for your feature, but it could alse be wrapped all up in a single flag like :

Scaffold-DbContext (...) -OutputDir Models -ContextNamespace <project>.Models -SchemaHierarchy [single|subfolders]

Like that, impact on the current feature may be minimun..

[jmevel]

I totally agree with @olavorn's idea. Now I only have 2 choices:

• Change my partial classes' namespace to the one of my Scaffolded models (I want the other way)
• mix all my partial classes together (Scaffolded and non-Scaffolded)

I like none of these choices, I would much prefer be able to specify the namespace of my Scaffolded models so I could store my partial classes in separate folders

[adayIvey]

i would also like to be able to define my namespace when scaffolding the db, has there been any traction with this?

[divega]

@aday12345 This issue is in our backlog milestone. That means we don't have immediate plans to work on it. I am however clearing up the milestone to re-discuss the priority. If anyone wanted to make a contribution here, we would be happy to consider it too.

[ajcvickers]

Note: when designing/implementing this, also consider the issues raised in #8852

[adayIvey]

just wondering if there has been any progress on defining the name space when scaffolding an existing db

[ajcvickers]

@aday12345 We discussed and even though we are doing some work in the background for reverse engineering, unfortunately we don't think this specific issue fits in the schedule for 2.1.

[adayIvey]

ok, thanks.

Is the any usage documentation for scaffolding the list all the options and switch?

[smitpatel]

@aday12345 - Use Get-Help Scaffold-DbContext in Package Manager console or dotnet ef dbcontext scaffold --help if you are using dotnet CLI

[ajcvickers]

@aday12345 Also https://docs.microsoft.com/en-us/ef/core/miscellaneous/cli/dotnet

[adayIvey]

thanks

[Pets]

@bricelam Is there any development for a flag, or any other option, for having the schemas separates in the different folders?

[redoz]

Seems a lot of people want this (myself included) any chance this will actually make it into EFCore soon?

[RudyCo]

We NEED this ! :-)

[markusschaber]

I see two problems with namespaces / schemas in databases, with contradicting requirements:

• Use those to structure a big database context with lots of tables, e. G. by different aspects of the product (e. G. User Management, Invoices, Stock, ...)

• Use schema name for tenant implementations, and passing the schema name to the DB Context before working with the data. All schemas replicate the same identical layout (represented by the DB Context), but separate data (one per tenant / region / division / ...).

I see use cases for both, and AFAICS, both are not supported well yet as of EF Core 2.1.

[dlebee]

What I did for my code ef core scaffolder is that I used meta tags,

which allows to specify the namespace like so

YourProjectName.[SCHEMA].Dal

will generate entities and do replace Schema with the schema name of your table.

If you want to take a look, its here: https://github.com/PoweredSoft/DbUtils

and implemented here:: https://github.com/PoweredSoft/DbUtils/blob/532853432774c94a42e23adbb44b86219a02e108/PoweredSoft.DbUtils.EF.Generator.SqlServer/Extensions.cs#L14

used by this: https://github.com/PoweredSoft/DbUtils/blob/532853432774c94a42e23adbb44b86219a02e108/PoweredSoft.DbUtils.EF.Generator/DatabaseGeneratorBase.cs#L72

I think that would be a good solution for the dotnet ef core scaffolder, allows flexibility to the developer to choose where the schema should be placed in the namespace.

[symbiogenesis]

The --context-dir parameter should respect the namespace conventions. Using a different context-dir justs creates a dbcontext with the same namespace as the model entites.

[bricelam]

@symbiogenesis Would you submit a new issue?

[Der-Kraken]

We have a very large MSSql database with different schemas and redundant table names. Some tables have dependencies to tables on different schema. That dependencies appears in Poco Model as a navigation member.

The current behavior to name the redundant tables with an increasing number suffix is not good because you did not know which table is used. We decide to use database-first for the first time because not to break all internal workflow at once.

Refactor manually all the tables is not really an acceptable solution because that work must be done daily, or at least weakly.

To run the scaffold tool for each schema separate is not working because the generated navigation properties between the schemas are missing then.

So we have a need that the scaffold tool generates subfolders/namespaces for each non-default schema.

@symbiogenesis You are right. We have generated the context outside of the model folder but the namespace does not match the directory. For me it looks like an issue, because that is not an expected behavior.

Our team experiments currently with EFCore.

[ErikEJ]

@Der-Kraken Have you tried EF Core Power Tools? it has a new table renaming option via a json file in the project.

[terrago]

@Der-Kraken Have you tried EF Core Power Tools? it has a new table renaming option via a json file in the project.

@ErikEJ: how does the table renaming option in "EF Core Power Tools" work? Is it the efpt.config.json?

[ErikEJ]

@terrago No - https://github.com/ErikEJ/EFCorePowerTools/issues/128#issuecomment-439692246

[mikethibault]

@ErikEJ Thanks, this does work. Although it would be really nice for it to not just prepend each class with the schema name, but to sort classes into schema-named directories. Is that currently possible with the rename feature?

[ErikEJ]

@mikethibault I suggest you create an issue in the EF Core Power Tools repo

[ajcvickers]

Note from triage: ping @bricelam for the simple change that can be made here.

[bricelam]

The simple fix is to uniquify class names so we stop writing over the top of other files. (that's a bug) The needs-design fix involves using the schema as part of the namespace. (that's more of a feature)

[ErikEJ]

EF Core Power Tools now allows you full control of both namespace and folder location!

[bricelam]

The simple fix is to uniquify class names so we stop writing over the top of other files. (that's a bug)

Looks like we already do this.

[AceCoderLaura]

I'm probably going to have to override CSharpEntityTypeGenerator to do this, but I'd much prefer it be part of EF Core because I'm not sure how I'm going to get the folders working.

[MrNunUther]

This appears to still be open -- has this simply been forgotten?

[ajcvickers]

@MrNunUther Not forgotten. Please vote (👍) for the issue if it is important to you. With 13 votes, it is currently at number 119 on the list of most voted issues.

[PedroS5499]

+1