Identifier generation strategy in reverse engineering

[roji]

I can see logic in CSharpUtilities that's responsible for generating a C# identifier out of a database column. In PostgreSQL it seems that the standard case is "snake case" (employee_name). It seems right for the reverse engineering process to convert this to camel case (EmployeeName).

So I was wondering if this is something that Npgsql should do in its own version of CSharpUtilities, or whether the universal CSharpUtilities should detect snake case and perform this task (I'm guessing there are instances where SqlServer or other databases contain snake case).

[natemcmaster]

This is a good question. The identifier generation needs to be revisited.

Currently RelationalScaffoldingModelFactory.GetEntityName handles generating the names. This can be overridden. This does 2 things: (1) ensures unique names for each entity type and (2) ensures these identifiers are CSharp-safe.

Future we will move (2) the csharpification of identifiers into the code-gen step (i.e. RelationalScaffoldingModelFactory will no longer need to return CSharp-safe identifiers.) We haven't designed code-gen API yet.

[rowanmiller]

Triage: We should just handle snake case in our CSharpUtilities. @roji do you want to send a PR for this?

[roji]

@rowanmiller sure I'll submit a PR soon.

[roji]

Note this probably means that single uncapitalized words are uppercased. If so there's no more need to detect C# reserved words and prefix them with underscore, since volatile becomes Volatile anyway

[divega]

Yay! Then at some point we'll have to start looking at the VB keywords instead! 😏

[natemcmaster]

Yup, this was one of the intentions of my comments above. IScaffoldingModelFactory.Create shouldn't be concerned with the targeted code-gen language.

[rowanmiller]

@lajones regardless of extension points, we should update EF to handle snake case

[lajones]

Fix checked in with a065b93.