-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Can't create foreignKey with Declarative Schema on table not created through DS #21770
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi @peterjaap. Thank you for your report.
Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:
For more details, please, review the Magento Contributor Assistant documentation. @peterjaap do you confirm that you was able to reproduce the issue on vanilla Magento instance following steps to reproduce?
|
Hi @engcom-backlog-nazar. Thank you for working on this issue.
|
Hi @peterjaap thank you for you report, It will be processed faster if you move this to https://github.com/magento/community-features |
@engcom-backlog-nazar but it's not a feature? It's a bug! |
@peterjaap according to devdocs, seems like no. |
@peterjaap |
@engcom-backlog-nazar could you elaborate on that? |
@peterjaap this mean that you can create a foreign key only with tables created by declarative schema, because all table data loaded now with checking db_schema.xml |
Ok maybe it's an idea to add that in plain English? And imho this is a serious impediment for the adoption of declarative schema. I've fallen back to writing InstallScripts again.... |
@peterjaap seems, like yes, but adding a check data table on install scripts, sounds like feature request. on my opinion |
I meant adding it to the docs instead of that weird sentence about |
@peterjaap devdoc always have not clearly documentation :) but you can create a PR to solve this here -> https://github.com/magento/devdocs |
@engcom-backlog-nazar The sentence about FL_ALLOWED_SEVERITIES does not mention the fact that you cannot add a foreign key referencing a table not created through db_schema.xml... I read the sentence again and again.. Nope. Seems like an issue. Like @peterjaap said, this is a serious impediment for the adoption of declarative schema. |
@Yonn-Trimoreau at this point, yes we must have ability to add foreign key to tables wich not created via db schema.xml but it's more a "feature" to my opinion, because db_schema.xml not cover this case. |
@engcom-backlog-nazar If we read the documentation again and take what is explicitly written about this issue:
Two things:
|
What is the status on this issue? |
This is not a feature request. This is implementing the backwards compatibility that was promised. |
✅ Confirmed by @sdzhepa Issue Available: @sdzhepa, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself. |
What is the status on this issue? |
Closing this issue as there is no plans to implement external references for the db schema. The reference to the table added in a custom way should be added in a custom way as well. |
Uh oh!
There was an error while loading. Please reload this page.
Preconditions (*)
Steps to reproduce (*)
db_schema.xml
foreignKey
with asreferenceTable
a table that isn't created/controlled through Declarative Schema (in my case a 3rd party extension's table)php bin/magento setup:upgrade
Expected result (*)
Actual result (*)
Notice: Undefined index: referenced_table_name_here in vendor/magento/framework/Setup/Declaration/Schema/Declaration/SchemaBuilder.php on line 352
When I edit
vendor/magento/framework/Setup/Declaration/Schema/SchemaConfig.php:77
and addprint_r(array_keys($data['table']));exit;
there, I get a list of all tables created by extensions that use Declarative Schema. The referenced table isn't one of them and thussetup:upgrade
throws an error.The text was updated successfully, but these errors were encountered: