[wp-trac] [WordPress Trac] #19866: Allow specifications of any wp_posts field(s) in WP_Query

[WordPress Trac]

#19866: Allow specifications of any wp_posts field(s) in WP_Query
-----------------------------+------------------------------
 Reporter:  bigdawggi        |       Owner:
     Type:  enhancement      |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Query            |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-patch close  |     Focuses:
-----------------------------+------------------------------
Changes (by boonebgorges):

 * keywords:  has-patch => has-patch close


Comment:

 Replying to [comment:15 sc0ttkclark]:
 > Fetching 'fields' => 'ids' or 'id>parent' seems to have the same issues
 you're speaking of. Would it be better to de-couple the tweaks you're
 speaking of from this ticket, and allow this ticket to move forward with
 the current caveats that we all accept with 'ids' and 'id>parent'?

 'fields => ids' is not really the same. The ID lookup in `WP_Query` is
 never cached. If 'split_the_query', a `SELECT ID` query is run, and post
 data is filled in from the cache; otherwise `SELECT *` is run, and the
 post cache is ignored. It's a special case. 'fields = id=>parent' does run
 up against the problems I've laid out. But the fact that we're doing
 something less than optimal in one case doesn't mean we should start doing
 it in all cases.

 I'm not sure that it's desirable to "move forward with the current
 caveats". If the proposed implementation is similar to 'id=>parent' - we
 modify the `SELECT` clause and then bail early - then our API will be
 implicitly suggesting that you save some overhead by fetching only the
 fields you need, which will not actually be true, since it'll totally miss
 the cache.

 There will still be cases (though I'd guess they'll be relatively rare)
 where it's measurably better to fetch fewer post fields. It seems to me
 that the best advice in these cases is to do a `WP_Query` with
 'field=ids', and then pass the found IDs, in PHP, to a direct SQL query
 that gets exactly what you want. That way, you have access to all the
 tools of `WP_Query` *and* you avoid the `SELECT *` overhead. This will not
 perform as well as `SELECT field_1, field_2...` at very large scales
 (like, say, during migration scripts), but in those cases you probably
 ought to be writing your own SQL anyway.

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