-
Notifications
You must be signed in to change notification settings - Fork 10.7k
Add migration to move orders from wp_posts to custom tables #32034
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
Conversation
jorgeatorres
left a comment
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.
Hi @vedanshujain!
This is brilliant work 💯. I particularly like the way you've abstracted migration of metadata in a way that can be easily re-used for each table.
Ignoring the TODO's for now, this looks good to me, with just one tiny exception (a typo) that I've flagged as that prevents the queries from working correctly.
I do have some general questions, which I'll leave not as part of the review but a comment in the PR.
plugins/woocommerce/src/Database/Migrations/CustomOrderTable/WPPostToCOTMigrator.php
Outdated
Show resolved
Hide resolved
| * | ||
| * @return bool|\WP_Error | ||
| */ | ||
| public function process_single( $post_id ) { |
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 might be intentional but thought I'd ask: shouldn't process_single() also migrate other meta (addresses and op data) for the migrated order?
I know this is not being used anywhere right now, but it's still a public function and might become handy later.
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.
Agreed, I was hoping to do it for later, but let me do it now.
| if ( count( $data['data'] ) !== $result ) { | ||
| // Some rows were not inserted. | ||
| // TODO: Find and log the entity ids that were not inserted. | ||
| echo 'error'; |
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.
Even at this point, would it make sense to make this an exception or WP_Error instead?
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.
hmm, so raising exceptions will break the entire migration flow, which is not ideal, and leave us in a weird state. but you are also right that logging might not be enough, let me think of better solutions here.
plugins/woocommerce/src/Database/Migrations/CustomOrderTable/WPPostToCOTMigrator.php
Show resolved
Hide resolved
| if ( count( $order_data['data'] ) !== $result ) { | ||
| // Some rows were not inserted. | ||
| // TODO: Find and log the entity ids that were not inserted. | ||
| echo ' error '; |
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.
See other related comments.
|
Questions: Please keep in mind that the items below might very well be already scoped,coming soon or even part of in-progress PRs, but given I'm new to the team and the COT project in particular, I thought I'd still ask them. Feel free to point me in the right direction if this has already been discussed or if there's a better place for these questions.
Thanks! |
I was planning to do this later, if you are happy with the overall approach than I can handle this now 👍🏽
So that would be handled by a different flow ideally which is not implemented yet. Basically, we will also hook on every order save if migrations are running in the background to handle updates one at a time.
Not at this point, but it's a good callout, let me see if we can handle it now. The biggest blocker in doing it is getting the order ID that was just inserted, but there should be a way. |
|
Marking the PR as draft again to address feedback. |
|
@jorgeatorres This is ready for review again with some caveats:
Other than that, this PR should take care of not adding duplicates, updating instead of inserting when needed, handling interrupted migrations, etc. There is a code sniff failing although violations are fixed, I am looking into it but it should not be a blocker for review. |
jorgeatorres
left a comment
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.
Hi @vedanshujain! 👋
Thanks for all your hard work on this 💯. Overall, it looks good to me, but I left a couple tiny observations. Please let me know what you think about those.
As for testing, I tested with a couple thousand orders in different configurations and didn't notice anything out of the ordinary, though we would have to test again once error handling is implemented as well as metadata migration.
|
|
||
| namespace Automattic\WooCommerce\DataBase\Migrations; | ||
|
|
||
| use function DeliciousBrains\WP_Offload_Media\Aws3\JmesPath\search; |
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 seems to have been added by mistake as this is not in WC core nor used in this class.
| * Generic migration class to move any entity, entity_meta table combination to custom table. | ||
| */ | ||
|
|
||
| namespace Automattic\WooCommerce\DataBase\Migrations\CustomOrderTable; |
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.
Might be a nitpick, but can we maybe use "Database" instead of "DataBase" in the namespace? It'd not only match the folder structure but also how the word is commonly used (i.e. "database"). If agreed, this would have to be modified in other classes too.
| } | ||
|
|
||
| /** | ||
| * Process migration for metadata for given post ids.\ |
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.
"\" at the end of the line.
|
@jorgeatorres Feedback addressed in c5e3150 . Do you think if we can merge this PR to the trunk, that way it will unblock work on UX implementation? I am meanwhile working on meta and better error logging in separate PRs. |
|
Hi @vedanshujain! Changes look good. Thank you!
I'm sure you have a better overview on all things COT than me, but the way I see it, it'd be best to merge this ASAP. Not only because of the UX work but also because it provides classes that might be useful for the other migrations that are still to be implemented. It also provides a small fix to the SQL schema which makes sense to get in soon. Even if we need to make further adjustments, I'm good with merging this right now. Does that sound good to you? |
jorgeatorres
left a comment
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.
LGTM 🚢. Beautiful work @vedanshujain! Thanks.
|
Hi @jorgeatorres, thanks for merging this pull request. Please take a look at these follow-up tasks you may need to perform:
|
|
Have you tested it with any of us working with this: https://github.com/liquidweb/woocommerce-custom-orders-table |
All Submissions:
Changes proposed in this Pull Request:
Closes #31766.
To add migrations, we add a general migration class that targets any combination of an entity table along with it's metadata table, described in the
MetaToCustomTableMigratorclass. We then use objects of this class inWPPostToCOTMigratorclass providing the necessary configuration for each custom table.How to test the changes in this Pull Request:
This PR should be tested along with #32052, #32053 and #32054. For code review, I have split it into four PRs, but for testing, it should be fine to only test thecot/migration-operational-dataas it has all the commits.We have now merged the separate PRs into this one, so all code is here and reviewing and testing just this one should be good enough.
cot/migration-operational-databranch (see PR Add migrations for operational data to custom order tables #32054).{prefix}_wc_orders,{prefix}_wc_order_addressesand{prefix}_wc_order_operational_datacreated by following steps from Add DB table structure for custom order tables. #31811.Check contents of
{prefix}_wc_orders,{prefix}_wc_order_addressesand{prefix}_wc_order_operational_datatable and verify that first 500 order records are migrated.Note the PR has many
TODOcomments, which will be handled by different PRs as the resolution for them is not clear at this time.Other information:
Changelog entry
FOR PR REVIEWER ONLY: