[buddypress-trac] [BuddyPress Trac] #6426: 'fields' => 'ids' for activity queries

[buddypress-trac]

#6426: 'fields' => 'ids' for activity queries
----------------------------------+------------------
 Reporter:  boonebgorges          |       Owner:
     Type:  enhancement           |      Status:  new
 Priority:  normal                |   Milestone:  2.4
Component:  Component - Activity  |     Version:
 Severity:  normal                |  Resolution:
 Keywords:  has-patch             |
----------------------------------+------------------

Comment (by boonebgorges):

 Cool! Thanks for working on this, r-a-y.

 >  If you pass 'fields=ids', this will bypass pagination parameters and
 return only activity IDs. I think it makes sense to bypass pagination in
 this case, but let me know if we shouldn't bypass pagination.

 I can see an argument either way, but I think that we should *not* bypass
 pagination in the case of `fields=ids`. If for no other reason than parity
 with `WP_Query`.

 > My question is should the activity ID be the array key

 My gut feeling is that we should only do this if we're going to do it for
 *all* activity queries (and perhaps for all content queries). WP's
 inconsistency on this point is not something we should try to emulate.

 https://core.trac.wordpress.org/ticket/19866#comment:6

 > Also if you pass 'fields=component,type', you do not get any activity
 meta cache fetching, activity comment appending or 'has_more_items'
 marker.

 As a developer, I would expect that I *would* get this stuff, except in
 the case of `fields=ids`. There are already independent ways of disabling
 meta cache fetching and activity comment appending. There's no way to turn
 off the 'has_more_items' checking, but if we think it's important to be
 able to disable that too, let's add a separate item for it.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6426#comment:5>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac