Efcore: Reverse Engineer: Cmd parameter to disable naming logic

[rowanmiller]

We have the ability to create a custom service that handles column => property naming (see https://gist.github.com/natemcmaster/353f4ab3efb4514eeaec846df28f0e24). However, some folks may want to opt out of our default logic and just have property names line up with column names. We think this makes sense to have as a top level parameter to the commands.

BTW we should have a design discussion about whether this literally just uses the column name, or makes some basic attempts to land with a valid C# identifier.

[ajcvickers]

A lot of people have been asking for this, so we should try to do it for 2.0.

[JuanIrigoyen]

In the previous version, I used the solution proposed by natemcmaster for regenerate my model https://gist.github.com/natemcmaster/353f4ab3efb4514eeaec846df28f0e24,

In the next version I used a modified version proposed by
https://romiller.com/2017/02/10/ef-core-1-1-pluralization-in-reverse-engineer/

But now with the last version nothing of the two works, who can I regenerate my model for disable name-changing logic.

[smitpatel]

@JuanIrigoyen - Solution posted by Nate should still work.

[lajones]

@ajcvickers @smitpatel @bricelam @divega Do we need to design this? I was getting going on a simple boolean flag --use-database-names which would switch this on. But do we want to consider a future where users can e.g. name a CandidateNamingService which we then search the project for? Even if we don't do the search right now it might argue for a --use-naming-service [service_name] flag instead (where for right now we only recognize PascalCase and UseDatabaseNames naming services)?

[divega]

@lajones can we bring this to the design meeting tomorrow?

On first thought I like the idea of adding a very simple flag that maps directly to what seems to be a common need, e.g. --no-pascal-case.

Bringing your own naming service already requires coding the service (or at least installing a NuGet package containing it), so I think it might be ok for that scenario to always require some tinkering with design time services.

But even if we later decide to do something in the command line to allow specifying custom naming services it won't necessarily obsolete the flag: We would just need to decide what happens when the user
specifies both settings.

BTW, Rowan mentioned in the original post that there we should decide whether the non-PascalCase option should still do some sanitization to land on valid C# identifiers. I tend to believe it should. Then maybe it makes sense to pass the state of the --no-pascal-case flag in the GenerateCandidateIdentifier method. Custom candidate naming services would be free to decide what to do with it (e.g. honor it, ignore it, or throw if it is set in a way that isn't supported).

[lajones]

Discussed in design mtg today. Outcome: we will use the simple boolean flag --use-database-names with no argument. It will imply a) that the candidate name we use will be just the database name as it was passed to us, and b) that we should make no attempt to pluralize/singularize names as we currently do.

There was also the suggestion that we move the existing singularize/pluralize step to _before_ the uniquify step (currently it's after and though we haven't come across issues with this they are theoretically possible).

[lajones]

Fixed with #8989 - commit dc7d379af.

[piyey]

Did anybody see fieldnames are still Pascalcased?

[ajcvickers]

@piyey Can you file a new issue with full details if the flag is not doing what you expect?

[piyey]

Ok @ajcvickers , I will search if someone else reported this issue.

[camelinckx]

Hi @piyey, did we file an issue for this, I can confirm the flag does not activate the feature? (i.e. field names are still PascalCased)

[bricelam]

9820