[wp-trac] [WordPress Trac] #42409: Add LIKE support to meta_key comparisons in WP_Meta_Query

[WordPress Trac]

#42409: Add LIKE support to meta_key comparisons in WP_Meta_Query
-------------------------------------------------+-------------------------
 Reporter:  Otto42                               |       Owner:
     Type:  enhancement                          |  mariovalney
 Priority:  normal                               |      Status:  assigned
Component:  Query                                |   Milestone:  Awaiting
 Severity:  normal                               |  Review
 Keywords:  good-first-bug has-patch has-unit-   |     Version:  4.9
  tests 2nd-opinion                              |  Resolution:
                                                 |     Focuses:
-------------------------------------------------+-------------------------
Changes (by boonebgorges):

 * keywords:  good-first-bug has-patch has-unit-tests => good-first-bug has-
     patch has-unit-tests 2nd-opinion
 * component:  Database => Query


Comment:

 [attachment:42409.3.diff] cleans up documentation and adds unit tests that
 demonstrate `compare_key` and `meta_compare_key` behavior. Unfortunately,
 the test in [attachment:42409.test.diff] doesn't work after recent changes
 to the way that SQL queries are generate by `$wpdb`.

 I agree with the comments above that we ought to keep the behavior
 consistent with `LIKE` for values. It's unfortunately that it's poorly
 named, but it'd be worse to have it inconsistent between keys and values.

 I agree with @kokers that [comment:4 we should add support for other
 compare operators] if we're going to introduce `compare_key`. Again, this
 is for consistency with `compare` (also, why not?). An updated version of
 [attachment:42409.3.diff] with less hardcoded logic regarding  `LIKE` /
 `=` would be welcome. If not, we can handle this additional enhancement as
 part of a separate ticket.

 More general wildcard support - ie, proper "LIKE" behavior with `%` - will
 probably have to be produced with a new operator name. Unfortunately it
 can't be "LIKE". "RAW_LIKE" is clunky but I'm having a hard time coming up
 with a better option. (The confusing thing here is that the upper-case
 convention implies that it corresponds to an actual MySQL operator, which
 `RAW_LIKE` does not.) Perhaps it'd be more semantically correct to add a
 parameter, something like:

 {{{#!php
 'meta_query' => array(
     array(
         'key' => 'foo\_%\_bar',
         'compare_key' => 'LIKE',
         'escape_wildcards_key' => false,
     ),

     // For values
     array(
         'key' => 'foo',
         'value' => 'foo%bar',
         'compare' => 'LIKE',
         'escape_wildcards' => false,
     ),
 ),
 }}}

 `escape_wildcards` and `escape_wildcards_key` would default to `true`, for
 compatibility.

 I am loath to introduce another parameter, but this feels more accurate to
 me than something like `RAW_LIKE`.

 Two questions:
 1. What do others think of this suggested syntax?
 2. Is there any reason to hold off on the improvement in
 [attachment:42409.3.diff] before making a decision about wildcard support?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/42409#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform