-
Notifications
You must be signed in to change notification settings - Fork 52
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
[Feature] Change EntityTypeName and EntityFileName transformer to be able to use IEntityType #232
Comments
services.AddHandlebarsScaffolding(options =>
{
// Put Models into folders by DB Schema
options.EnableSchemaFolders = true;
}); Does this meet your need? |
Ah I have seen that and it's handy but doesn't quite fit the bill. I was explicitly asked to prefix the class name with the schema by the lead developer. It would also help with the fact we have a bunch of duplicate table names across schemas, so being able to prefix might fix some of the Table, Table1, Table2, naming issues we run into. |
Have a look at the sample app and you'll see that DB schema names are represented as folders, which adds the schema to the namespace for each class within that namespace. This solves the problem of duplicate table names across schemas, because they are disambiguated by namespace, which is how it's done in C#. |
Ah I probably just muddied the waters mentioning duplicate tables. I had wanted to use schema folders, but it isn't up to me. My team lead is having to compromise between moving to modern .Net standards while keeping to some of the company's older, custom conventions. In this case, he opted to prefix schema names to entities to keep with the custom conventions. I could go into more detail but in the end we were hoping for more control over naming entities. That said if that's not something you think would be good to allow no worries. I can make my own fork for this specific project. |
@CDMayberry EF Core Power Tools allows you to do custom naming |
Ah I do keep forgetting about that, I'll consider that in the future. In this case I've used this Handlebars.Net + this in the past at other companies and really liked it. We had started to use it at my current company when I learned we needed to change how naming is handled. I wanted to see if this library was open to making that change before I look at other options. |
Don’t mind you submitting a PR, but the main thing I’d like to avoid is any breaking changes. Is there a way you can manage that?
|
I've got a couple of ideas, I'll spin up a fork and see if I can make it work. |
We also need this functionality as well. Can we also get the ability to know what the foreign table is in these property transformers, like the constructor and nav transformers? We really need to be able to know what the property's foreign table is in the relationship, so we know what to rename the types and property names correctly to. |
Closed #233 pending the .NET 8 upgrade. @mwmccallum, When you have time, we can circle back to have a look at this feature request. |
Is your feature request related to a problem? Please describe.
In a work project I'm currently using this in, all of our tables are in distinct schemas and it's been requested that the generated entities be prefixed with their schema name. Digging around I didn't see any way to prefix the schema, and the entity name and file transformer only passes the string name of the entity; there isn't an overload to that includes IEntityType unlike the other transformers.
Describe the solution you'd like
I would like to change the EntityTypeTransformationService objects to be able to take in an IEntityType for EntityType and EntityFile name transformations. This would allow for more control in naming entities. For me specifically would allow access to the GetSchema() method of IEntityType.
This would be a breaking change for the IServiceCollection extension AddHandlebarsTransformers2 if using EntityTypeName or EntityFileName arguments and for any developers currently using their own implementation of IEntityTypeTransformationService, though it seems easy enough to fix if someone were using them.
Not sure if there is was a particular reason why EntityTypeName and EntityFileName transformers don't include an IEntityType version, but barring any context I'm missing or worries about breaking changes, I'd be happy to write the PR.
The text was updated successfully, but these errors were encountered: