Introduce WP_Meta_Query

[scribu]

Similar to WP_Tax_Query.

Also, make get_meta_sql() public.

Related: #16742

[scribu]

Related: #17011

[ryan]

Do we still need the meta query re-parsing hack from [17552] with this?

[scribu]

Probably not, but I would like to get the current patch in before we start messing with query vars again, since it's blocking other tickets.

[scribu]

Nevermind, I see I forgot to remove the extra call to _parse_meta_query(), which would cause a fatal error.

[scribu]

17165.2.diff​ removes the remaining call to _parse_meta_query() and also introduces a get_meta_sql() function similar to get_tax_sql(), for convenience.

[scribu]

17165.3.diff​ makes the second call to $this->meta_query->parse_query_vars( $q ); just before the !empty( $this->meta_query->queries ) check.

[greuben]

Patch refreshed.

@scribu: Your patch(refreshed) but just a minor change, I have moved $this->meta_query = new WP_Meta_Query(); to WP_Query::query(); to avoid fatal errors when directly calling WP_Query->query(); See #17118

[scribu]

Unlike tax_query, we don't need to set any query flags based on meta_query.

Therefore, we can call meta_query->parse_query_vars() only once, at the beginning of WP_Query::get_posts().

This is what 17165.6.diff​ does.

[scribu]

At this point, the WP_Meta_Query class isn't very useful.

However, it will become useful when the 'relation' arg comes into play. See #17011

[ryan]

Now that we're on PHP5 can we lose call_user_func_array() on get_sql() and simply do $this->meta_query->get_sql( 'post', $wpdb->posts, 'ID', $this)?

Should the constructor call parse_query_vars() on $meta_query?

[scribu]

Replying to ryan:

Now that we're on PHP5 can we lose call_user_func_array() on get_sql() and simply do $this->meta_query->get_sql( 'post', $wpdb->posts, 'ID', $this)?

Done: 17165.7.diff​

Should the constructor call parse_query_vars() on $meta_query?

No, the constructor accepts only the value of the 'meta_query' var, while parse_query_vars() accepts the entire array of query vars.

When the 'relation' arg is introduced, parse_query_vars() will probably call the constructor, not the other way around.

[scribu]

I have updated the unit-meta-query.php​ file and it passes all tests.

[greuben]

One small change, check if parsed queries are arrays.
Try this query

$q = new WP_Query(
array(
	'fields' => 'ids',
	'ignore_sticky_posts' => true,
	'meta_query' => array(
		'test' => 'test',
		array(
			'key' => 'foo',
			'value' => array( 'foobar' ),
			'compare' => 'IN'
		)
	)
) );
echo  $q->request;

The result

SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts INNER JOIN wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id) INNER JOIN wp_postmeta AS mt1 ON (wp_posts.ID = mt1.post_id) WHERE 1=1 AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private') AND wp_postmeta.meta_key = 't' AND CAST(wp_postmeta.meta_value AS CHAR) = 't' AND mt1.meta_key = 'foo' AND CAST(mt1.meta_value AS CHAR) IN ('foobar') GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 5

[scribu]

If we're going to start checking for is_array(), might as well implement the 'relation' arg in one go.

Care to refresh and integrate the patch from #17011 into the latest patch here?

[greuben]

Replying to scribu:

If we're going to start checking for is_array(), might as well implement the 'relation' arg in one go.

The reason I've used 'test' and not 'relation' in the example code above is because #17011 is a different ticket and in case if doesn't go in or causes regressions we should still be able to avoid that kind of sql queries.

Care to refresh and integrate the patch from #17011 into the latest patch here?

Sure managing the relation arg here seems more relevant.

[scribu]

17165.relation.2.diff​: parse_query_vars() populates a $meta_query arg and passes it to the constructor for further processing.

unit-meta-query.2.php​: update and added 2 tests for the 'relation' arg.

[ryan]

(In [17699]) Introduce WP_Meta_Query and relation support. Props scribu, greuben. fixes #17165 #17011