WPSC meta caching still needs implementing

[benhuson]

Just noticed this note in the code. https://github.com/wp-e-commerce/WP-e-Commerce/blob/master/wpsc-includes/meta.functions.php#L15

[JeffPyeBrook]

@benhuson cool. just wanted to be sure I wasn't totally missing something. it can happen

[JeffPyeBrook]

Doing a little meta related code audit, found a meta type called wpsc_downloads, it is updated but never read? Anyone know any history?

[garyc40]

@JeffSparkleGear: Thanks for the PR. I'm reviewing it now and will post my comments in the pull request.

As for wpsc_downloads, I think it's a legacy meta type from 3.7 and is only used in the 3.7 -> 3.8 database upgrade routine. It's not being actively use in 3.8 any more as far as I know.

Also, had a brief discussion with Justin last week (or was it two weeks ago?) and I think a hybrid approach would be the best compromise:

• Your code for the WPSC_Meta class would be used (after more serious review and feedback from core devs) for existing object types. However, we'll need to use that filter within get_metadata() and hook our WPSC_Meta functions in, check the object type, and query our custom wpsc_meta table. The idea is, no matter what the underlying implementation is, a third party dev could always reliably call get_metadata( $id, $type ) without having to know whether behind the scene, WPSC_Meta or the core WP meta API is used.

By using the WPSC_Meta class you wrote for existing meta types, we avoid having to write database migration routines which are quite potentially buggy.

• For any new object types, such as customer meta, we'll have discussion for each one of them and decide whether it makes sense to use the core WP meta functions, or our WPSC_Meta implementation. As for customer meta I feel strongly that we need a separate database table for that and use WP meta functions (which it seems you've successfully converted the idea into that PR!), as that table could easily become bloated.

I'll review your PR in a minute. Thanks again for your contribution!

[JeffPyeBrook]

Thanks @garyc40.

We should probably migrate the existing cart_item meta type. It is much better suited to the new infrastructure, and there is only one 'sku' row being set into the database, and it's access is well defined.

FWIW, I don't think a db migration migration is going to be a big problem. Code to init the table on creation is in the latest pull request. The approach you suggested, abandoning the data in place is probably a good one.

[JeffPyeBrook]

@garyc40 For the customer meta, the timestamp field on the meta value is already available. What would make it really useful is a function call that would make it easy to find meta matching specific timestamp criteria.

would something like get_{$META_OBJECT_TYPE}_meta_by_timestamp ($callback, $timestamp, $comparison = '<' ) work;

Supported $comparison would be the allowed SQL numeric comparison operators. (<, > , <=, ...)

$callback would be invoked for each meta that has a timestamp field matching the comparison

Shall I add that to the pull request?

[JeffPyeBrook]

@garyc40 ... This is what I am testing for the function prototype to iterate meta by timestamp. I think it should work for what we need to do for the customer data, and anything else I can reasonably foresee. The function will be available for all other custom meta types as well. Let me know if you think it is ok.

/**
 * Calls function for each meta matching the timestamp criteria.  Callback function
 * will get a single parameter that is an object representing the meta.
 *
 * @since 3.9.0
 *
 * @param function $callback function to invoke once for each meta matching criteria 
 * @param int $timestamp timestamp to compare meta items against
 * @param string $comparison any one of the supported comparison operators, (=,>=,>,<=,<,<>,!=)
 * @param string $meta_key restrict testing of meta to the values with the specified meta key
 * @return int count of meta items matching the criteria
 */

function wpsc_get_customer_meta_by_timestamp ($callback = null , $timestamp = 0 , $comparison = '> ', $metakey = '' ) 

[JeffPyeBrook]

I had a thought related to providing an upgrade path. It might be possible to create and move all existing data on an upcoming point release. And at the same time re-create the existing meta table as a view that is a union of the distinct meta tables. It would provide ongoing read access to the data, but would break write access.

My intuition tells me that database upgrades are probably hard enough without having to worry about all the things that can happen on different mysql installations with sql views. But not having to support an upgrade like this before, I wanted to throw the idea out there.

[JeffPyeBrook]

@JustinSainton @benhuson Guys this is starting to feel real good right now. I have it working on a private mirror of our main production site.

The table create and even the upgrade, with post upgrade hook, work really well. I have tested this against our production database of past sales and all of the custom historical information displays perfectly in the sales logs, packing lists and emails.

This is ready for a good review.

I have the cart_item meta changes just about ready for a separate commit. That code that would be dependent on this pull request being available. It may be useful to look at the cart_item meta code it is a nice example of how to use this meta api. The branch that I will use for the pull request is available in my repository at "JeffSparkleGear/Custom-Checkout-Options"

@garyc40 if you can give me a little insight into the customer id generation and any security concerns you might have I might be able to take a crack at that over the next couple of weeks.

I am thinking about a 'customer service' plugin that would allow someone to help a customer on the web get the right things into the cart by making the cart sharable and visible to someone on the backend. It would go well with the priced product options plugin that I am using. I'm just guessing that others would find it useful. Any thoughts?

[JeffPyeBrook]

Happy to report that I have had the wpsc custom meta using wordpress infrastructure in production for a week now and it is working well.

[JustinSainton]

Calling this fixed as of 0e0018738c82e72fdbc56136cc72dc9ce55cb1af. New bugs? New tickets, please.