Fix MigrationGenerator for some columns with underscore

[nikdejan]

Before this fix for columns like this:
agent_party_id: id foreing:agents.party_id
migration was generated like this:
$table->foreignId('agent_party_id')->constraints(); Which is a problem because this syntax assumes table name is 'agent_parties'.

[jasonmccreary]

Thanks for this. I would appreciate seeing a test fixture that drove out the solution or document/verifies the change.

[nikdejan]

Added strict, fixture-driven test for agent_party_id: id foreign:agents.party_id.
Before: generator used bare ->constrained() (only correct for {table}_id).
After: generator emits ->constrained('agents','party_id') and preserves existing cascade behavior.
Fixtures mirror the migration stub (docblocks + FK disable/enable).

[jasonmccreary]

In looking at this more closely, I think there are a few issues…

First, Blueprint probably needs a better way to distinguish a custom primary key. I believe you are attempting to do so with your agent_id: id column. But that should probably be more like agent_id: id primary.

Second, when a table has a custom primary key, Blueprint should be smart enough to propagate that to the correct places. In this case, passing it to constrained().

If Blueprint did both of these things, then you should really just need to write:

agent_party_id: id foreign:agents

I'm going to close this, but may revisit with a fuller solution. Of course, you are welcome to as well.

[nikdejan]

I agree. What you just described: agent_party_id: id foreign:agents is a behavior I expected when I first time started using blueprint. It should be a feature.
But BUG I was talking about is different thing, although related to what you said.
Docs:
If you are not following Laravel's naming conventions, you may set the attribute on the foreign modifier. Blueprint supports either the foreign table name or THE TABLE NAME AND COLUMN name using dot notation.
So, when not following conventions, and using custom table name and column, as per docs, if column name has an underscore and if accidentally foreign key = concat(table, primary_key) migration is not generated correctly.

[jasonmccreary]

I agree there is a bug here. My point is that this PR only contains part of the solution. Maybe that's fine. But I'd personally like to have the other items fixed too.