Fatal error: Call to a member function get_data_store()...

[krif]

Hello,
I tried the migrate command with the latest beta (3). About half way through, the process stopped with "Killed" being returned.

Trying the wp wc-order-table migrate command again to continue the process returned an error part way through.

"Fatal error: Call to a member function get_data_store() on boolean in /home/PATH-TO-SITE/wp-content/plugins/woocommerce-custom-orders-table/includes/class-woocommerce-custom-orders-table-cli.php on line 96"

Trying the command again results in the same error as above.

Running the backfill command after this also returns "Killed" part way through.

Anything I can do to remedy this?

P.S. Thank you for this project. Our wp_postmeta table as become big and is slowing down the orders backend, big time.

[krif]

Update:
I repaired the original database and copied it to the testing site. The above error no longer appears. However, the migration still doesn't work.

"Error: A database error occurred while migrating order 28597: Duplicate entry '28597' for key 'PRIMARY'."

This is retuned almost immediately after running the migrate command. I see a new "wp_woocommerce_orders" table was created, and it contains just one row, the row contains an order with order_id 28597

Thanks again.

[stevegrunwell]

@krif Thank you for the detailed report!

The "Killed" error is typically the result of the process not getting enough memory, so I'll be sure to focus on memory management and garbage collection as I continue to revise the migration script.

The data store issue was reported in #43 and resolved in #46, but is currently only in the develop branch (you mentioned you're running Beta 3, here's a look at what's changed since that tag)

As for the duplicate key issue, this looks like a good place to focus some testing, thanks for bringing it to our attention! :)

[krif]

@stevegrunwell Thank you for the reply. In case it helps troubleshoot, I'd like to mention that the entry '28597' in the duplicate key errror corresponds to the latest order in the database. Cheers :)

[stevegrunwell]

Great information, thank you!

[dream-encode]

I'm having the same "duplicate key" issue. Extending on @krif 's report, it's the first order in the batch it tries to process, not necessarily the latest order.

In my debugging, it seems that the WC_Order_Data_Store_Custom_Table->populate_from_meta is being called twice. However, I'm unable to determine why or where it's being called the first time.

This has something to do with WC_Order_Data_Store_Custom_Table->get_order_data_from_table also being called twice. I think it's not setting the $this->creating flag, but it's acting like there's some concurrency going on.

I've added a whole bunch of debug output all over the place, but I cannot see why a row is being inserted in the custom table before WC_Order_Data_Store_Custom_Table->populate_from_meta is officially called directly inside the migrate method.

[dream-encode]

@stevegrunwell Here's some more information.

To get this working, I flattened the code, pulling all the external methods inside the migrate method in the CLI class. Here's what I've found so far.

1. wc_get_order_types is used to get the correct WC_related post types for the DB queries. 'shop_order' works, but 'shop_order_refund" doesn't. This is because only certain order post meta is created, and it's associated with the parent order. So, things like "order_key" will not exist for refund orders.
2. There's a WC()->version check to handle the "_billing_email" and "_customer_user" meta in older versions prior to 3.3.0. However, shouldn't the version check compare the order's version and not the plugin version?
3. The "duplicate key" database error seems to stem from the code not knowing when an order is being inserted or updated in the loop. It checks $this->creating in the WC_Order_Data_Store_Custom_Table->update_post_meta() method. The issue is definitely in this block somewhere related to that flag.

[stevegrunwell]

@dream-encode Thanks for digging into this!

wc_get_order_types is used to get the correct WC_related post types for the DB queries. 'shop_order' works, but 'shop_order_refund" doesn't. This is because only certain order post meta is created, and it's associated with the parent order. So, things like "order_key" will not exist for refund orders.

The order refund stuff is being handled in #52 (originally reported in #45)

There's a WC()->version check to handle the "_billing_email" and "_customer_user" meta in older versions prior to 3.3.0. However, shouldn't the version check compare the order's version and not the plugin version?

The issue isn't with the WooCommerce version at the time of the order, so much as WooCommerce having some hard-coded queries prior to 3.3.0 that we couldn't override via filter. 7c877ca is the commit where that was introduced, and the commit message holds a little more detail:

WooCommerce prior to 3.3.x lacked the woocommerce_pre_customer_bought_product filter, and instead had a hard-coded SQL query against the postmeta table within wc_customer_bought_product().

As a result, versions prior to 3.3.0 need to still store the billing email and customer ID in the post meta table.

The filter in question was added in woocommerce/woocommerce@7606666de9.

The "duplicate key" database error seems to stem from the code not knowing when an order is being inserted or updated in the loop. It checks $this->creating in the WC_Order_Data_Store_Custom_Table->update_post_meta() method. The issue is definitely in this block somewhere related to that flag.

I'll dig in further and see what I can find, thank you!

[stevegrunwell]

I've spent the better part of the day trying to reproduce the issue locally, but haven't had much luck. I did add a few tests to reproduce some of the likely causes (#53).

@dream-encode If you run the migration command against the current develop branch, does the issue persist?

[dream-encode]

@stevegrunwell Due to the dumpster fire project I'm currently using this on, I can't really checkout anything. The version of WordPress is old, and WooCommerce is ~2.4. Needless to say, it's a mess.

I've gotten the migration to run finally by flattening the script. I also hit on the issue in #55 very early, and hard-coded the $delete.

It's running now, but two things happen along the way.

1. Script is encountering a memory error. This may be due to the hacky nature of the current project. So, I just re-run the command until down to the last batch.
2. When processing the last batch, I run in to the same issue reported by Infinite loop during migrate script #57.

[dream-encode]

@stevegrunwell So, I pulled down the develop branch after seeing a few PRs lately. On first run, I get the "duplicate key" error:

There are 28754 orders to be migrated.
Error: A database error occurred while migrating order 122534: Duplicate entry '122534' for key 'PRIMARY'.

If I immediately run the command again, it cycles to the very next order:

There are 28753 orders to be migrated.
Error: A database error occurred while migrating order 122533: Duplicate entry '122533' for key 'PRIMARY'.

Also, I ran the command with the --debug flag each time, and it didn't give any more information on the actual error.