-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reverse Engineer: Better support for namespaces #3988
Comments
You should get either the 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? |
We should re-discuss this, it was one of the biggest complaints about reverse engineer in EF6. |
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. |
Note: the "DB schema translates to C# namespace" suggestion was also made as part of #3861 (and many other places I'm sure). |
Hope this get developed soon :) It will make it lot easier when generating contexts with different schemas. |
@rowanmiller Hi, In addition to @roji's, another (more general I guess) aproach also making use of a parameter I want to scaffold all tables into Model\Design :
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:
This would output in @roji's scenario would be accomplished with something like this:
|
@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. |
@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 :
Like that, impact on the current feature may be minimun.. |
I totally agree with @olavorn's idea. Now I only have 2 choices:
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 |
i would also like to be able to define my namespace when scaffolding the db, has there been any traction with this? |
@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. |
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. |
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
This comment was marked as spam.
+1 |
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.
The text was updated successfully, but these errors were encountered: