[wp-trac] [WordPress Trac] #29642: Support complex (nested, multiple relation) queries in WP_Meta_Query

[WordPress Trac]

#29642: Support complex (nested, multiple relation) queries in WP_Meta_Query
------------------------------------+------------------
 Reporter:  boonebgorges            |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  4.1
Component:  Options, Meta APIs      |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+------------------

Comment (by boonebgorges):

 [https://core.trac.wordpress.org/attachment/ticket/29642/29642.3.patch
 29642.3.patch] is a refresh that reflects the unit tests committed in
 r29799, along with some documentation fixes.

 The main change in 3.patch is that I've broken the recursive logic into an
 `abstract class WP_Recursive_Query`, which `WP_Meta_Query` now extends.
 This exact recursive logic will be shared by `WP_Tax_Query` (#29738) and
 `WP_Date_Query` (no ticket yet, but I've got a patch almost done). Use of
 `WP_Recursive_Query` in a nutshell:

 1. Your extending class is responsible for its own
 sanizitation/regularization of the params passed to the constructor. See
 `WP_Meta_Query::sanitize_query()`. It would be nice to provide some help
 in `WP_Recursive_Query` for this sanitization, but the requirements of the
 extending classes are just too different. The sanitized params should then
 be set to `$this->queries` in your constructor.

 2. Your extending class should contain a `public function get_sql()`,
 which is responsible for accepting whatever params are required for your
 query logic, setting them to class properties as necessary, calling
 `$this->get_sql_clauses()` to start the recursion logic, manipulating the
 clauses returned as required (`WP_Meta_Query` just passes them through a
 filter for backward compatibility), and then returns them. The param and
 return value syntax of `get_sql()` in Meta, Tax, and Date are all
 different, so there's no way to provide this functionality in a shared
 base class (even as an abstract method - they take different default
 arguments, which violates strict standards).

 3. Your extending class must contain a `protected function
 is_first_order_clause( $query )`, which should return true when `$query`
 is at the tip of a recursive branch, and `protected function
 get_sql_for_clause( $clause, $parent_query )`, which does all the specific
 SQL-building logic for your clause.

 I've got the abstraction for Meta, Tax, and Date working locally.
 Obviously, they all depend on having `WP_Recursive_Query`, so I've opted
 to post the `WP_Meta_Query` version here first - mainly because Meta is,
 in a couple ways, the most complex case.

 I'm looking for feedback on this proposed architecture. Splitting the
 recursive logic out like I've done is the DRY thing to do, and it paves
 the way for building future SQL-generating classes like this - I have a
 few in mind already ;). At the same time, I'm sensitive to the concern
 that we build APIs that are flexible and do not place overly rigorous
 demands on developers, so I've tried to be modest in the requirements
 placed on extending classes (eg with regard to shared param sanitization).

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