Naming of Fk in Entity framework core context

Question

I am working on a EF core 2.2 rest api project. I created my models and context using dbfirst approach and the "Scaffold-DbContext" command.

The model and context work but I noticed that in the context code there are explicit names for foreign keys:

    modelBuilder.Entity<TrackingPoints>(entity =>
    {
        entity.HasKey(e => e.IdPosition);

        entity.ToTable("myTable");

        entity.Property(e => e.CaseId).HasColumnName("CaseId");

        entity.HasOne(d => d.IGeoPosition)
            .WithMany(p => p.TrackingPoints)
            .HasForeignKey(d => d.IPositionId)
            .OnDelete(DeleteBehavior.ClientSetNull)
            .HasConstraintName("FK__Track__iGeoP__278EDA44");
    });

(the actual table has more fields, but I keep it short)

My concern is about the FK name (HasConstraintName). Actually this code has informations about the relationship of data between the table, but it has also an explicit name for the FK constraint.

I noticed that in different instances of this db (dev, preproduction...) the same constraint has different names.

I would like to know if I have to give to the FK constraint the same name on all instances of the db or if the mapping will work flawlessly despite the naming mismatch of the constraint. In the dev environment it works, and the FK name matches the one in the model. In different environments the first tests are ok, but I do not know if the naming issue can create some obscure and hard to find side effects.

Answer 1

Constraint/index names are part of the physical relational database mappings and are important only for code first migrations in case the migration requires dropping the constraint. If the name doesn't match, it won't be able to drop it and the whole migration will probably fail.

If you continue using database first approach with re scaffolding (or updating with some external tool) the context when database changes, the constraint/index names won't have any affect on the EF Core behavior.

The problem will arise if at some future point you decide to switch to code first migrations. Hence although not strongly necessary for your current workflow, it would be safer to keep the names one and the same in all databases.