Consider making a generic product meta table available for use by custom types

[manospsyx]

Hey folks,

Kudos for the great work here! It was a pleasure to read the blog post - this is going to be a big step towards making WC a more scalable platform.

I liked how the new tables maintain a balance between WP functionality while making WC more performant. Keeping products in the posts table really makes sense; at the same time moving their meta into their own table should boost performance on sites with tons of meta dumped into the post_meta table.

It's still early to provide any useful feedback on the migration process, but I'll keep an eye here and test everything once "on-the-fly" data migration is baked into the plugin.

One suggestion I have at this time would be to consider making a generic product meta table available for use by custom product types that need to store/retrieve their own props in a performant manner. Currently, the idea seems to be that all these will be saved in the post meta table, which will ultimately prevent custom product types from fully reaping the benefits of custom product tables.

Having the table in place, along with all methods needed to add/update/delete product meta will allow extension developers to utilize the product meta table in their data stores for any product props that must be loaded every time a product object is created.

This will ensure that sites heavily relying on custom product types can benefit from the new structures as much as sites utilizing core/built-in product types only.

Happy to discuss details and help build this into the plugin!

Again, kudos for the great work 💯

PS: Ultimately, a custom product meta table would mainly help extensions that do 'join' operations on their own props (saved as meta). Reason: Since the new data stores still extend the WC_Data_Store_WP store that reads all product meta from the post meta table, it seems that large post meta tables may still be a performance bottleneck?

[kloon]

@franticpsyx thanks for the recommendation, it was something we considered but decided not to for now since the focus was to get core fields moved first.

Definitely an improvement we would like to see, so will keep this open for discussion as a feature request.