[wp-trac] [WordPress Trac] #31045: Ordering a Query Using Multiple Meta Keys

[WordPress Trac]

#31045: Ordering a Query Using Multiple Meta Keys
------------------------------------------+-----------------------------
 Reporter:  Funkatronic                   |       Owner:
     Type:  feature request               |      Status:  new
 Priority:  normal                        |   Milestone:  Future Release
Component:  Query                         |     Version:  trunk
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:
------------------------------------------+-----------------------------

Comment (by boonebgorges):

 > Every meta query clause gets aliased, even the main one. Any orderby
 call to meta_value will default to the first one.

 Yes. We pretty much already do this; see
 https://core.trac.wordpress.org/browser/tags/4.1/src/wp-
 includes/meta.php#L1353. It makes sense to me to then fill in the 'alias'
 key for each clause with the calculated value.

 > let WP_Meta_Query create the ORDER BY clauses and store them in an array
 where the aliases are the keys

 I hesitated at first, but on reflection I think it's a good idea for
 `WP_Meta_Query` to do some of this work. That way, it'll be possible to do
 the same orderby magic in other places where meta queries are used
 (`WP_Comment_Query`, `WP_User_Query`). However, I'd rather not attempt to
 build partial SQL statements and pass them around. Here's an alternative
 thought: `WP_Tax_Query` builds a flat list of "queried_terms" as it parses
 the arguments passed to the class.
 https://core.trac.wordpress.org/browser/tags/4.1/src/wp-
 includes/taxonomy.php#L774 What we did something similar in
 `WP_Meta_Query`? This flat array would contain aliases (and perhaps even
 be keyed by alias, though I don't think it matters too much), and could be
 used in `WP_Query` to look up the necessary cast for the meta value. I
 think this is somewhat better than assembling the orderby clauses in
 `WP_Meta_Query` itself, for two reasons: (1) it's not great practice to
 pass around partial SQL chunks between classes (my suggestion would pass a
 structured array instead, and leave it up to the "client" - `WP_Query` -
 to build the SQL), and (2) my suggestion would leave the door open for
 different kinds of custom query manipulation than just ORDER BY, since all
 the clause data would be readily available in a flat array.

 > parse_orderby looks for aliases; if it finds one, it pulls the right
 clause from the meta_query object. If it finds meta_value or
 meta_value_num, it calls the first/main clause.

 +1

 Does this make enough sense to do a proof of concept?

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