-
Notifications
You must be signed in to change notification settings - Fork 9.4k
fix for #38585: Signed primary columns changed value #38920
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
base: 2.4-develop
Are you sure you want to change the base?
fix for #38585: Signed primary columns changed value #38920
Conversation
…ead of unsigned definition which is loss of usable values - changed unsigned attribute for value_id column for tables from original list + catalog_category_entity_datetime customer_address_entity_datetime
Hi @KrasnoshchokBohdan. Thank you for your contribution! Add the comment under your pull request to deploy test or vanilla Magento instance:
❗ Automated tests can be triggered manually with an appropriate comment:
Allowed build names are:
You can find more information about the builds here For more details, review the Code Contributions documentation. |
@magento run all tests |
@magento run Functional Tests B2B Functional Tests CE Functional Tests EE |
Failed to run the builds. Please try to re-run them later. |
@magento run Functional Tests B2B |
1 similar comment
@magento run Functional Tests B2B |
@magento run Functional Tests CE |
@magento run Functional Tests EE |
Failed tests seems flaky to me |
@magento run all tests |
We are moving this PR |
@magento run all tests |
@magento run Unit Tests Static Tests WebAPI Tests |
Failed to run the builds. Please try to re-run them later. |
@magento run Unit Tests |
@magento run WebAPI Tests |
@magento run Magento Health Index |
@magento run Static Tests Semantic Version Checker |
Failed to run the builds. Please try to re-run them later. |
@magento run Static Tests, Semantic Version Checker |
@magento run Functional Tests B2B, Functional Tests CE, Functional Tests EE |
Hi! Now it seems to look better, what do you think? |
Thank you for the updation! @ihor-sviziev, as suggessted by you in here also in other comments like here, it seems that @KrasnoshchokBohdan have made the changes accordingly. Requesting you for the review. Thank you! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@KrasnoshchokBohdan, I just reviewed this PR again, and see that by adjusting type of the columns we were getting issues like this:
Column definition "product_tax_class_id" and reference column definition "c
lass_id" are different in tables "tax_calculation" and "tax_class"
Column definition "customer_tax_class_id" and reference column definition "
class_id" are different in tables "tax_calculation" and "tax_class"
Column definition "tax_calculation_rate_id" and reference column definition
"tax_calculation_rate_id" are different in tables "tax_calculation" and "t
ax_calculation_rate"
Column definition "tax_calculation_rule_id" and reference column definition
"tax_calculation_rule_id" are different in tables "tax_calculation" and "t
ax_calculation_rule"
Column definition "tax_calculation_rate_id" and reference column definition
"tax_calculation_rate_id" are different in tables "tax_calculation_rate_ti
tle" and "tax_calculation_rate"
You've reverted these changes, which is great, thanks!
I am wondering if people might have similar issues with other tables that you've changed just because they have foreign keys to these tables in custom extensions, and Magento doesn't have those custom extensions.
I believe the number of potentially affected people will be higher than the number of people getting to the issue you're trying to resolve. Those who need it can apply these changes as a patch and verify that they do not affect their Magento installation.
Having that in mind, I don't know if we should accept this pull request.
Please give us your thoughts on this.
@magento run all tests |
@ihor-sviziev |
@rostilos, unfortunately it won’t help because of dependencies in 3rt party extensions. These extensions still will have a db schema files, which declare the current state. I don’t think it’s possible to make backward compatible version at all, while benefit from this change will be for pretty small amount for installations |
Hi @engcom-Hotel, Can you please go through @ihor-sviziev's comment and review this PR again to decide whether we can proceed ahead with this PR or not. Thank you! |
Hello @KrasnoshchokBohdan, I agree with @ihor-sviziev's input here. This PR may impact some third-party extension that uses these tables as foreign keys. I think we can close this PR. Please suggest @KrasnoshchokBohdan @rostilos @ihor-sviziev. Thanks |
We are closing this PR as the fix may impact the 3rd party extensions. |
I heard some whispers a few months ago about a potential upcoming Magento 2.5.0 version, so maybe if that actually happens, we can open this PR again, because it's a new major version where backwards compatibility breaking is allowed |
@engcom-Hotel |
I don't mind re-opening it for 2.5, but I didn't hear any news about it |
Hi @KrasnoshchokBohdan. Thank you for your contribution!
Allowed build names are:
You can find more information about the builds here For more details, review the Code Contributions documentation. |
Hi @KrasnoshchokBohdan , Thanks for the contribution! Thanks |
Description (*)
changed "unsigned" attribute for "value_id" column for tables from original list (This is applicable to the following tables:... from author post) + catalog_category_entity_datetime, customer_address_entity_datetime
Related Pull Requests
Fixed Issues (if relevant)
Manual testing scenarios (*)
Questions or comments
Contribution checklist (*)