Skip to content
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

How to change casing of tables and columns? #505

Closed
jholovacs opened this issue Jul 4, 2018 · 2 comments
Closed

How to change casing of tables and columns? #505

jholovacs opened this issue Jul 4, 2018 · 2 comments

Comments

@jholovacs
Copy link

I want my db tables and columns to be snake_cased in my postgres db as opposed to the C# standard of PascalCased for entity classes. Capitalization in postgres is a real pain, because you have to wrap everything in quotes for any manual or specialized queries, and we do a lot of that.

In the previous version of Npgsql.EntityFrameworkCore, I was able to do this by replacing the default versions of the ISqlGenerationHelper, IQuerySqlGenerator, and IHistoryRepository, and this worked swimmingly... but now everything is different and since updating to the latest and greatest this can't work any more.

What do I need to do now to change the casing of my column names and table names so that everything still works, but the entity FooBars with a FooId column renders, migrates, and reads like CREATE TABLE "foo_bars" ("foo_id" int... ?

@austindrenski
Copy link
Contributor

I believe that #259 is the most recent discussion about convention-based naming patterns.

It wasn't merged, but fa4865e provides an implementation that should still work in 2.1.

@roji
Copy link
Member

roji commented Jul 5, 2018

This question is best treated at a general EF Core level, rather than as an Npgsql provider question. It has been asked several times, and frankly the easiest way seems to be simply writing some code in your model's OnModelCreating() which goes over all your entities and properties and sets their their name to whatever you want. This is easy, portable and is much less brittle than replacer services in the provider.

Aside from that I'm not aware of any massive changes in the APIs of the services you mentioned above, so it's surprising you're into significant issues.

Am going to close as there's nothing to do here in the provider itself, but feel free to post more questions.

@roji roji closed this as completed Jul 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants