[buddypress-trac] [BuddyPress Trac] #4988: bp_has_activities to accept multi scope

[buddypress-trac]

#4988: bp_has_activities to accept multi scope
-------------------------+------------------
 Reporter:  henrywright  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  2.2
Component:  Activity     |     Version:  1.2
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------

Comment (by boonebgorges):

 > This is probably the worse example for endorsing nested relation queries
 ;)

 Yes, it was a very terrible example. My brain was too tired to think of
 more realistic ones.

 > I kinda like the current syntax as it's easy to write scopes for. We
 also have to keep in mind that whatever syntax we decide will be used by
 plugin authors.

 Yes. Aesthetically I prefer the `'component' => array( 'groups' )` etc
 syntax. However, the introduction of 'compare' alongside 'relation' in the
 same subquery shows how the syntax is limiting. Your example above for
 using 'compare' kinda assumes (at least semantically - and, at a glance,
 technically, though I'd need further testing) that the current clause only
 contains a single filter. Consider the following:

 {{{
 array(
     'compare' => 'NOT IN',
     'component' => 'groups',
     'item_id' => array( 4, 10 ),
 ),
 }}}

 What does this do? Does 'NOT IN' apply to *both* clauses? What if I only
 want it to apply to one? In some cases, I might be able to work around
 this by breaking it out into two separate clauses:

 {{{
 array(
     'relation' => 'AND',
     array(
         'compare' => 'NOT IN',
         'component' => 'groups',
     ),
     array(
         'compare' => 'IN',
         'item_id' => array( 4, 10 ),
     ),
 ),
 }}}

 But this might not work in all cases, because of the various kinds of
 groupings that might be required. (Do we want to require plugin authors to
 do De Morgan's transformations in order to fit their meaning into our
 syntax?)

 Another way to put the general point: 'relation' talks about the
 relationship between siblings in the clause, while 'compare' talks about
 the internal structure of a sibling within the clause. Permitting them
 both on the same level of subquery makes the syntax a bit more terse, but
 also introduces the opportunity for confusion. (This confusion does not
 exist in my recursive suggestion: a 'compare' param can only appear in a
 lowest-level subquery, while a 'relation' only works to relate
 subqueries.)

 So, (a) does the above make sense?; (b) Am I right? (it's confusing!); (c)
 Do we want to sacrifice some expressiveness and clarity in order to make
 the syntax a bit simpler (less nesting required)? Regarding (c), I'm kinda
 leaning toward the following answer: let's sketch up what our *core*
 queries would look like on each syntax (you've already done it for your
 syntax, I'd just have to do something comparable for what I'm suggesting).
 If it turns out that core queries require several levels of confusing
 nesting, it's likely to be even worse for plugin authors building complex
 stuff, and we should lean toward the simpler syntax (sacrificing some
 expressiveness). If it turns out our core queries are fairly easy to
 understand, let's go with the more general and flexible syntax.

 What do you think?

 > What are some other 'compare' types we want to support? I still have to
 do some further tweaking, but what do you think about diverging from the
 WP_Meta_Query syntax?

 Honestly, for now, I think we stick with IN and NOT IN. Once we're settled
 on the API format, let's get complete test coverage, and then worry about
 what others we might want to support. (My gut says: arithmetic operators
 (<, <=, >=, >, BETWEEN, NOT BETWEEN), but not LIKE/REGEXP.)

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