Open Orteko opened 4 months ago
Yeah, that's getting deep. I could see fixing this for a single build
run, but I wonder about future runs. Blueprint would either need to "remember" this custom table name or you would need to specify it, always. I'll have to think on that.
Issue:
First up - thanks for the project, wish i'd found it earlier as it's going to save me a lot of grunt work!
On to the issue - as per https://github.com/laravel-shift/blueprint/pull/577 & https://github.com/laravel-shift/blueprint/issues/639 we appear to have the ability to use set a custom table name via meta when defining a model.
This works and
$table
is added to the model with the expected value.However, when attempting to create a second model (Service in the included example) that references a model which has a custom table name defined, that custom table name is not used when creating the foreign key.
With the draft.yaml in this report - when running migrations a
ERROR: relation "customers" does not exist (Connection: pgsql, SQL: alter table "service" add constraint "service_customer_id_foreign" foreign key ("customer_id") references "customers" ("id"))
exception will be produced.The culprit appears to be that Generators/MigrationGenerator.php @ line 318 - updating this line to include the table in the constrained() method "fixes" the issue, and both the models with custom table names and those without appear to migrate as expected.
However it then would operate identically to the if statement below it so i'm uncertain as to the underlying reason for these two if statements to be different:
The 'meta' functionality is also not documented on the website as far as I can see so i'll open a separate issue at https://github.com/laravel-shift/blueprint-docs.git assuming it is expected to be supported.
draft.yaml: