Names and default names for keys, constraints and indices

Open
#12,837 19 comments 0 reactions 1 assignee View on GitHub

Nobody has claimed this yet.

Assessment

This issue has not been assessed yet.

Description

area-conventions area-scaffolding customer-reported needs-design

While working on #12821, I noticed some that may merit some discussion.

When scaffolding, RelationalScaffoldingModelFactory checks the database name for keys, constraints and indices, comparing them against the default name EF Core would assign to this index. The idea is presumably to avoid useless scaffolding HasName() calls which would bloat OnModelCreating().

Now, at least in the PostgreSQL case (but I think also the others), a name is always returned for keys/constraints/indices. PostgreSQL has its own defaults: primary keys that haven't been explicitly named are called {table}_pkey, etc. This means that for a typical database that has been created without specifying names, HasName() will be scaffolded everywhere because the PostgreSQL defaults aren't the same as the EF Core defaults (PK_{table}).

There seem to be two options:

  • Current behavior: always take the name reported by the database. This bloats OnModelCreating() with HasName() calls on every single key, constraint and index. But it does have the advantage of round-trippability (exact names are preserved from the scaffolded database).
  • Alternative behavior: have the database model factories omit names when those names are the database defaults, leading to null names and less HasName() everywhere. Since EF Core must specify names when creating keys/indices, it would see nullls and default create indexes and keys with its own defaults.

Basically it's a choice between round-trippability (current behavior) and a leaner OnModelCreating(). I'm not sure to what extent the former is an actual goal.

What do you guys think?

Dominant language
C#
Stars
14.8k
Forks
3.4k
Avg merge
2d 5h
Merged PRs (30d)
134

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/efcore

All issues in dotnet/efcore

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.