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
Limit index length to 191 characters by default, additionally connect HPOS to verify DB tooling. #39250
Conversation
Test Results SummaryCommit SHA: 6d11563
To view the full API test report, click here. To view the full E2E test report, click here. To view all test reports, visit the WooCommerce Test Reports Dashboard. |
Hi @rrennick, Apart from reviewing the code changes, please make sure to review the testing instructions as well. You can follow this guide to find out what good testing instructions should look like: |
1 similar comment
Hi @rrennick, Apart from reviewing the code changes, please make sure to review the testing instructions as well. You can follow this guide to find out what good testing instructions should look like: |
Additionally, connect verify db tooling to order tables when they are enabled.
@vedanshujain Should we update this message to reflect the limit imposed by the filter? |
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.
Code looks good but I didn't test it yet. I left that for after resolving the discussion points.
@@ -366,6 +366,7 @@ private function handle_data_sync_option_changed( string $feature_id ) { | |||
|
|||
if ( ! $this->data_synchronizer->check_orders_table_exists() ) { | |||
$this->data_synchronizer->create_database_tables(); | |||
|
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.
This looks accidental.
@@ -2584,6 +2584,23 @@ public function get_database_schema() { | |||
$operational_data_table_name = $this->get_operational_data_table_name(); | |||
$meta_table = $this->get_meta_table_name(); | |||
|
|||
/** |
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.
Would it be worth adding this filter in its own function in a utility/helper class as we may find more uses for it as we work through some of the other upcoming data storage projects?
@vedanshujain Not for this PR but there are couple small things I noticed:
|
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.
Nice work on this @vedanshujain . It tested great for me.
Thanks a lot for the input on this @rrennick - much appreciated! @vedanshujain, do you want us to create Issues for the suggestions that Ron has made? |
@vedanshujain I just noticed that WC is giving a warning that WC Smooth Generator is not compatible with HPOS, even though it has been declaring compatibility for quite a while now. I used |
It's not registered as compatible with the two new features added in this PR. |
In #38993, the `custom_order_tables` feature was split into two separate features, one for choosing which tables to use, and one for toggling data synchronization. My understanding is that this was done in order to have both of those settings appear on the Features settings page, instead of having to create a separate page for other HPOS-specific settings. However, this added some extra complexity, which then led to #39250 causing a regression where extensions that declared compatibility with HPOS were no longer recognized as compatible. With this PR, we're reverting back to only having one "feature" for HPOS, but introducing a way to add additional setting controls to the Features settings page.
* Ensure FeaturesController is aware of correct HPOS option keys This is a piece of a change that is already in trunk, but it needs to be backported to 8.0 (see #39250). This ensures that the feature ID and the option key match for each of the two HPOS-related features that were introduced in #38993. * Add changefile(s) from automation for the following project(s): woocommerce --------- Co-authored-by: github-actions <github-actions@github.com>
In #38993, the `custom_order_tables` feature was split into two separate features, one for choosing which tables to use, and one for toggling data synchronization. My understanding is that this was done in order to have both of those settings appear on the Features settings page, instead of having to create a separate page for other HPOS-specific settings. However, this added some extra complexity, which then led to #39250 causing a regression where extensions that declared compatibility with HPOS were no longer recognized as compatible. With this PR, we're reverting back to only having one "feature" for HPOS, but introducing a way to add additional setting controls to the Features settings page.
In #38993, the `custom_order_tables` feature was split into two separate features, one for choosing which tables to use, and one for toggling data synchronization. My understanding is that this was done in order to have both of those settings appear on the Features settings page, instead of having to create a separate page for other HPOS-specific settings. However, this added some extra complexity, which then led to #39250 causing a regression where extensions that declared compatibility with HPOS were no longer recognized as compatible. With this PR, we're reverting back to only having one "feature" for HPOS, but introducing a way to add additional setting controls to the Features settings page.
In #38993, the `custom_order_tables` feature was split into two separate features, one for choosing which tables to use, and one for toggling data synchronization. My understanding is that this was done in order to have both of those settings appear on the Features settings page, instead of having to create a separate page for other HPOS-specific settings. However, this added some extra complexity, which then led to #39250 causing a regression where extensions that declared compatibility with HPOS were no longer recognized as compatible. With this PR, we're reverting back to only having one "feature" for HPOS, but introducing a way to add additional setting controls to the Features settings page.
In #38993, the `custom_order_tables` feature was split into two separate features, one for choosing which tables to use, and one for toggling data synchronization. My understanding is that this was done in order to have both of those settings appear on the Features settings page, instead of having to create a separate page for other HPOS-specific settings. However, this added some extra complexity, which then led to #39250 causing a regression where extensions that declared compatibility with HPOS were no longer recognized as compatible. With this PR, we're reverting back to only having one "feature" for HPOS, but introducing a way to add additional setting controls to the Features settings page.
In #38993, the `custom_order_tables` feature was split into two separate features, one for choosing which tables to use, and one for toggling data synchronization. My understanding is that this was done in order to have both of those settings appear on the Features settings page, instead of having to create a separate page for other HPOS-specific settings. However, this added some extra complexity, which then led to #39250 causing a regression where extensions that declared compatibility with HPOS were no longer recognized as compatible. With this PR, we're reverting back to only having one "feature" for HPOS, but introducing a way to add additional setting controls to the Features settings page.
In #38993, the `custom_order_tables` feature was split into two separate features, one for choosing which tables to use, and one for toggling data synchronization. My understanding is that this was done in order to have both of those settings appear on the Features settings page, instead of having to create a separate page for other HPOS-specific settings. However, this added some extra complexity, which then led to #39250 causing a regression where extensions that declared compatibility with HPOS were no longer recognized as compatible. With this PR, we're reverting back to only having one "feature" for HPOS, but introducing a way to add additional setting controls to the Features settings page.
In #38993, the `custom_order_tables` feature was split into two separate features, one for choosing which tables to use, and one for toggling data synchronization. My understanding is that this was done in order to have both of those settings appear on the Features settings page, instead of having to create a separate page for other HPOS-specific settings. However, this added some extra complexity, which then led to #39250 causing a regression where extensions that declared compatibility with HPOS were no longer recognized as compatible. With this PR, we're reverting back to only having one "feature" for HPOS, but introducing a way to add additional setting controls to the Features settings page.
In #38993, the `custom_order_tables` feature was split into two separate features, one for choosing which tables to use, and one for toggling data synchronization. My understanding is that this was done in order to have both of those settings appear on the Features settings page, instead of having to create a separate page for other HPOS-specific settings. However, this added some extra complexity, which then led to #39250 causing a regression where extensions that declared compatibility with HPOS were no longer recognized as compatible. With this PR, we're reverting back to only having one "feature" for HPOS, but introducing a way to add additional setting controls to the Features settings page.
Additionally, connect verify db tooling to order tables when they are enabled.
Submission Review Guidelines:
Changes proposed in this Pull Request:
This PR introduces two changes:
191
characters as we do for other WooCommerce schema. This is needed because at least in the MyISAM engine, the maximum index size can only be 1000 bytes, which is occupied by 192 chars with utf8_mb4 encoding.verify_db_tool
with the HPOS schema if it's enabled (or if data sync is on). This tools alerts the site admin if a table is missing.Closes #39051
How to test the changes in this Pull Request:
Using the WooCommerce Testing Instructions Guide, include your detailed testing instructions:
Delete the custom orders tables
tool.) $collate ENGINE = MyISAM;
instead of just) $collate ;
.Specified key was too long; max key length is 1000 bytes
.Verify base database tables
tool. It will identify the missing table and show this error:Verifying database... One or more tables are still missing: wp_wc_orders_meta
.Verify base database tables
tool. It should show that all tables are present as expected.Changelog entry
Significance
Type
Message
Comment