Feature Request: Add primaryFor() method to Blueprint (mirrors foreignIdFor() pattern)

[avenjamin]

When defining pivot table migrations, foreignIdFor(Model::class) gives a clean, model-aware syntax.

There's no equivalent for composite primary keys, which means you end up mixing styles:

// Current — inconsistent
$table->foreignIdFor(ModelA::class);
$table->foreignIdFor(ModelB::class);
$table->primary(['model_a_id', 'model_b_id']); // raw strings

// Proposed — consistent
$table->foreignIdFor(ModelA::class);
$table->foreignIdFor(ModelB::class);
$table->primaryFor([ModelA::class, ModelB::class]);

Proposed implementation:

/**
 * Specify the primary key(s) for the table using model class names.
 *
 * @param  string|array  $models
 * @param  string|null  $name
 * @param  string|null  $algorithm
 * @return \Illuminate\Database\Schema\IndexDefinition
 */
public function primaryFor($models, $name = null, $algorithm = null)
{
    if (! is_array($models)) {
        $models = [$models];
    }

    $columns = [];

    foreach ($models as $model) {
        if (is_string($model)) {
            $model = new $model;
        }

        $columns[] = $model->getForeignKey();
    }

    return $this->primary($columns, $name, $algorithm);
}

[shaedrich]

Migrations should ideally be without dependencies and side effects. Having the model class there is a bad idea, because the migration class can get out of date and not be runnable anymore when the model is deleted.

[avenjamin]

Understood, however there is some precedence here with existing methods accepting Model classes:

• foreignIdFor()
• dropForeignIdFor()
• dropConstrainedForeignIdFor()

If the consensus is that migrations shouldn't have dependencies then perhaps we should be deprecating these?

Personally I prefer the syntax with the Model class.

[shaedrich]

This syntax is helpful for static code analysis, no doubt, and otherwise, I would advocate for its use, but it breaks the promise that migrations can always be run.

One could make an argument for deprecation, however, the counterargument could be that since they are there, devs are allowed to make their own mistakes if they really want to 🤔

[avenjamin]

I suppose there will be arguments either way - I'm a solo web dev and I'm not fussed either way. I've just been googling to try find a best practice around the migration dependencies.

Claude had this to say:

The "migrations as historical record" argument
The strongest argument against foreignIdFor is that migrations are a permanent historical record of schema changes. Purists argue they shouldn't depend on application code (models) at all — because models evolve, get renamed, or deleted, while migrations are frozen in time. A migration from 2019 referencing a model that was renamed in 2022 is technically broken, even if it'll never run again.

The "DRY / typo prevention" argument
The counter-argument is that foreignIdFor prevents typos (user_id vs users_id) and stays in sync with Laravel's naming conventions automatically.

What most teams actually do

• Greenfield projects with a stable model layer: foreignIdFor is common and convenient
• Shared/open-source packages: tend to avoid it to reduce coupling
• Teams with strict migration hygiene: prefer foreignId for the self-contained property

I take it you're in the former camp and I'm in the latter 😄
Either way I'd still like primaryFor() as an option to go along with foreignIdFor()

Hopefully more people chime in as well.

[shaedrich]

In the past, I was in the latter, at work, I'm in the former, and for current spare time projects, I'm somewhere in the middle 😅

[avenjamin]

In the meantime, I've created a few macros in a Provider in case anyone wants to test the concept - BlueprintMacroProvider.php.

Add to providers in config/app.php

Example could be something like this:

public function up(): void
{
    Schema::create('post_tag', function (Blueprint $table) {
        $table->foreignIdFor(Post::class)->constrained()->cascadeOnDelete();
        $table->foreignIdFor(Tag::class)->constrained()->cascadeOnDelete();
        
        $table->primaryFor([Post::class, Tag::class]);
        $table->indexFor(Post::class);
    });
}