Plural DbContext names, singular tables?

[atrauzzi]

As the title says, I think one convention that might be worth having as a toggle is to inflect singular table names from plural DbContext properties.

🙂

[roji]

@bricelam I know we occasionally mention pluralization but I don't have a good picture of this... Does pluralization/singularization belong in a naming conventions plugin like this one?

[bricelam]

We don’t do it at runtime in the product because fixing any pluralization bugs would be a breaking change. We have plans to do it at design time for reverse engineering. IMHO, it’s totally fine in an extension like this where the bar for breaking changes is a lot lower.

But, just removing the convention that uses the DbSet name as the table name would be enough for this issue, right?

[atrauzzi]

I think the idea is that a convention is still desired, just that it inflects for table names as .net prescribes plural DbSets and some DBs use singular, snake cased equivalents.

[roji]

I agree singularization should be OK in this extension, anyone know of a good singularizer?

[bricelam]

The Roslyn team uses https://github.com/Humanizr/Humanizer for name reccomendations

[bricelam]

But wouldn't doing dotnet/efcore#11160 light up with this extension?

[nerdpad]

I had to use Humanizer in my project to achieve this. It will be great if it was part of this extension.

[VitalyV]

Do we have any progress?

[roji]

Not at the moment, there's too many other things going on. I can try to review a PR though.

[ThomasHeijtink]

Hold on a moment. Am I the only one who just wants the name of the tables to reflect the name of the type rather than that of some singularized form of a plural name which most of the time is already a pluralized form of the type?

So you have a entity called Person (which most likely is a wrong name for the type anyway. But ok). Then people spend time debating really hard that it should be People instead of Persons. But have at least agreed with each other that all table names should be in singular from. So they are back to square one.

Shouldn't we just add an option to use the type name as naming: UseTypeNameForTableNamingConvention and leave out all the complexity of some Humanizer?

[roji]

@macshack I think you have things confused - this extension (EFCore.NamingConventions) just changes the casing of identifiers (e.g. PascalCase to snake-case), it does not do any plural->singular transformations (or vice versa). This specific issue is asking for this extension to do singularization (but it does not currently do that).

As for EF itself, as @bricelam noted above, no pluralization/singularization is done at runtime.

So I think things already work as you want?

[jeremycook]

You can easily remove the pluralization convention in EF Core 7 onward with the following.

// In your DbContext
protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
    configurationBuilder.Conventions.Remove(typeof(TableNameFromDbSetConvention));
}

• Official docs: https://learn.microsoft.com/en-us/ef/core/modeling/bulk-configuration#pre-convention-configuration
• An EF Core community standup video that covers this capability in great depth: https://www.youtube.com/live/6apfe1L1FhY

[atrauzzi]

Will that make the table names singular, or just result in an error as a result of them not being explicitly specified per-model?

[jeremycook]

@atrauzzi EF Core doesn't need the "TableNameFromDbSetConvention" convention to name tables. If that convention is removed it will use the name of the class if the [Table] attribute has not been applied to it. I use the technique I mentioned in projects where I have a mixture of EF Core 7+ and Dapper for example.

[LeTranAnhVu]

@jeremycook Your suggestion did work in my case. Thank you!

[buden]

@jeremycook is that possible to use your solution with EF Core 6? The ModelConfigurationBuilder.Conventions property is not available there, and I can't find any way to access it.

[jeremycook]

@buden It looks like I misspoke about it being available in EF Core 6. Looking at that version of the API, I also don't see the ModelConfigurationBuilder.Conventions property. It is there in the EF Core 7 version of the API.

[kalatchev]

@atrauzzi

IMHO good practice for DB design is to name tables in plural form, e.g. if your entity is called Sale, the table have to be sales (in PG). The reason is that this table contains many sales. As far as I remember, that comes from many years, back to the days of first publications about Active Record pattern. EF is more or less the implementation of this pattern, i.e. should follow its logic.

[atrauzzi]

@kalatchev - The active record pattern messes around with inflectors (gooses or geese?) and adds complexity while offering no benefit. When you say "the active record pattern", you're likely referring to Rails ActiveRecord which is just one implementation.

It's down to perspective and to be honest, I'm not arguing the point you make. More the conclusion you come to as a result as your argument is really more of a bias around one specific circumstance. For example, if I'm writing a query, I could also argue that when I'm referencing a table, it's more logical to have non-plural names in conditions: where dog.breed = 'daschund'. This is in contrast to dogs.breed..., because I'm comparing one dog, not all of them.

Either way, the more important point above is that having an inflector be part of my database logic is not desirable and that the plural forms of names tend to introduce more complexity. Whether for machines, or even for people (English not a first language, something I deal with daily).

[markushaslinger]

You can easily remove the pluralization convention in EF Core 7 onward with the following.

// In your DbContext
protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
    configurationBuilder.Conventions.Remove(typeof(TableNameFromDbSetConvention));
}

Note: this breaks when using TPC, the concrete tables generated are still pluralized leading to inconsistency

IMHO a table is the entity type (singular) while the set of tuples is the entity set (plural).
It even shows in how we define DbSet<Car> Cars: a set of type Car called Cars.

I really hope we will finally get a simple way to reliably override this default.