Creating PrimaryKeys constraint get different constraint names

[Sherif-Ahmed]

Describe the bug
Creating PrimaryKeys constraint get different constraint names

To Reproduce
I have an initial migration for table creation

public class InitialMigration : ForwardOnlyMigration
{
    public override void Up()
    {
        Create.Table("MyTable")
            .WithColumn("Id").AsInt32().NotNullable().PrimaryKey()
            .WithColumn("Name").AsString(400).NotNullable();
    }
}

This will generate a constraint name "PK_MyTable", and in a later migration I have to re-create the primary key because of a table rename

public class Migration2 : ForwardOnlyMigration
{
    public override void Up()
    {
        Delete.PrimaryKey("PK_MyTable").FromTable("MyTable");
        Rename.Table("MyTable").To("NewTableName");
        Create.PrimaryKey().OnTable("NewTableName").Column("Id");
    }
}

This will generate a constraint name "PK_NewTableName_Id"
Is this intended or I had an issue.

Expected behavior
Same constraint name convention for example "PK_NewTableName" based on DefaultPrimaryKeyNameConvention

Information:

• OS: Windows 11
• Platform: .NET 8.0.4
• FluentMigrator: 5.2.0 "in-process runner"
• Database Management System: SQLServer

[TheSquidCombatant]

Obviously, the observed difference in the name of the primary key occurs due to the fact that, when creating primary key via creating a table, the DefaultPrimaryKeyNameConvention class is used to generate the name, and when creating a standalone primary key, the DefaultConstraintNameConvention class is used to generate the name.

I agree that it would be correct for the name for the primary key to be generated the same in all cases. I have created a pull request with the appropriate fix, please check #1803.

I won’t reassure you and I’ll say right away that I’m not a maintainer. For now, I suggest keeping in mind that the default primary key name is not guaranteed. And each time explicitly set the name of the primary key.

[jzabroski]

This would be a breaking change, but seems reasonable. For now you can implement a different naming convention as a workaround.