Discussion for Announcement 167: Table names now taken from DbSet names (starting in RC2)

[ericwj]

Where is the comments/discussion link for EF Core: Table names now taken from DbSet names (starting in RC2) Or I'll just drop my thought on this right here:

Kudos @rowanmiller & team for this, it's great!

It always felt like there was some hard to understand reason why this couldn't be done or some data modelling purists didn't want it and truth be told I've not thought of asking for this in EF7, but now finally this is really going to be as intuitive as many people probably thought with me it could be.

Correct me if I'm wrong, I believe EF has always had these complex mapping strategies and pluralization etc while the property of the DbContext is there most of the time, pluralized and spelled correctly for EF to just use.

[PhillipVoyle]

Will the [Key] attribute still be respected?

[miguellira]

@PhillipVoyle Did you mean the [Table] attribute? I can't see how this change would impact the naming of Keys.

[miguellira]

@divega Does this affect the naming of objects created by EF in a many to many scenario?

[divega]

@PhillipVoyle @miguellira I don't think [Key] is affected, although I may be missing something. [Table] should continue to work as a way to explicitly pick a name explicitly.

Does this affect the naming of objects created by EF in a many to many scenario?

EF Core currently doesn't support modeling many-to-many directly without a link entity type. The name of the table for that link entity type will follow the same rules as any other entity type, e.g. the table will be named after the type unless there is a DbSet for it in the context, the name is specified using [Table] fluent or metadata APIs.

[miguellira]

@divega Thanks for the quick response. So for the following model: http://docs.efproject.net/en/latest/modeling/relationships.html#many-to-many

Since the link entity type is not exposed as a DbSet you would end up with dbo.Posts, dbo.Tags, and dbo.PostTag... not the plural form dbo.PostTags - correct?

[divega]

@miguellira Yes, I would expect dbo.PostTag to be the table name in this case.

[divega]

Correct me if I'm wrong, I believe EF has always had these complex mapping strategies and pluralization etc while the property of the DbContext is there most of the time, pluralized and spelled correctly for EF to just use.

@ericwj Yes, I think that synthesizes very well our thinking on this: With this improvement EF Core can leverage naming choices made by the developer instead of being in the business of processing the words and producing plurals for table names in a specific language (we did that in Code First for previous versions of EF and it turned out to be a dead end, especially since any bug fix on the pluralizer becomes a breaking change in the runtime). Design-time/reverse engineering tooling is a different story. We may still add something there: #3060.

[entitycontext]

As someone who prefers singular table names but likes plural DbSet names, I disagree with this approach. In my opinion, having the PluralizingTableNameConvention as a default in previous EF versions was a mistake and I would prefer to see that removed as a default while keeping table names the same as class names.

Apologies for bikeshedding and maybe I am just out of step with industry practices, but it seems to me far more common that people use singular table names in SQL, while plural DbSet names match better with C# conventions.

[miguellira]

@entitycontext I generally agree with you. The singular/plural table name is a matter of personal preference and the singular form is often chosen to avoid dealing with irregular plurals (e.g. person/people).

That said, I think the EF teams wants to avoid that issue by defaulting to a name that you have chosen in your model that should make sense in your database.

Fortunately, if it doesn't sit well with you, you can always override it via attributes or fluent definitions.

BTW, other technologies (like Ruby/Rails/ActiveRecord) defaults to plural form so "industry practices" will vary by the technologies chosen. 😃

[entitycontext]

@miguellira I agree it really is just a matter of personal preference, but it's annoying to have to fight against the defaults when you don't agree with them. See also: LazyLoadingEnabled and OneToManyCascadeDeleteConvention in EF6, both of which I strongly prefer to have turned off and also arguably should be off by default.

Since I want singular table names, I will consider using singular DbSet names as well for new projects in EF Core rather than fighting against the default behavior in the model builder. Honestly, that wouldn't be a terrible thing and might even be better for mentally switching between SQL and LINQ - would just feel weird at first, since I've been pluralizing the DbSet names for so long.

[miguellira]

@entitycontext If you're the only one that will be working on that code do what works for you and keeps you happy. However, if you expect others to see something like:

public DbSet<Person> Person { get; set; }

when they're used to seeing something like:

public DbSet<Person> People { get; set; }

and not question your approach... be prepared to do some explaining. 😃

[ericwj]

There is a two-liner in the announcement however that you could tweak a little to change all table names to the type name and keep the People property name too.