Allow disjunctive conjunction (OR) of arguments
| Project: | Views |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Jump to:
Hello! First of all: Thanks for the great module! It's a great help and saves a lot of SQL hacking, great!
Today I experimented with this module and had a look at the generated SQL statements. As it seems, arguments I add to a view are interpreted in an additive way resulting the SQL having the according filtering statements connected with 'AND' in its WHERE-part. It is not possible to conjunct arguments in an disjunctive way, which would be reflected with 'OR' conjunctions in the resulting SQL query.
Example: Let's say i want to filter after two arguments, the first giving the user name and the second some taxonomy term name: A request like somehost/Clint/Drupal will be reflected in the SQL statement like:
...
WHERE
(users.name = 'Clint') AND
(term_data.name = 'Drupal')If I now want to filter with another third taxonomy term argument, an appropriate query like somehost/Clint/Drupal/Cms should be interpreted as:
...
WHERE
(users.name = 'Clint') AND
(term_data.name = 'Drupal' OR
term_data.name = 'Cms')But as all arguments are connected with 'ADD', in the moment it will result in a useless SQL query:
...
WHERE
(users.name = 'Clint') AND
(term_data.name = 'Drupal') AND
(term_data.name = 'Cms')Thus, I propose the introduction of a way to apply arguments in a disjunctive way (OR). Maybe it is possible to bundle arguments of the same type into an OR-group. Seems like a natural fit for me, because (at least in my example) it makes no sense to filter the same argument type twice in an additive way: (term_data.name = 'Drupal') AND (term_data.name = 'Cms') is a pointless request.
#1
See also http://en.wikipedia.org/wiki/Conjunctive_normal_form for a formal write up on what you're proposing. I'd like to see this.
To do so, we'd probably have to change the view's object, such that filters are grouped, instead of being a flat list. Also, we'd need UI changes to add the filter groups. Finally, there would be the problem of exposed filters. From a data perspective, exposed filters would be fairly simple, but from a UI perspective, it could be very confusing. For example, if I had a view with the filter groups
Taxonony Terms (exposed)
Author = Fred
OR
Taxonomy Terms (exposed)
Author = Joe
It could be very confusing to have two sets of terms. Moreover - what I always wanted those taxonomy terms linked (i.e. the say terms selected in each OR group).
This is a good idea, but I think we should spend a little time specing out exactly how the system behaves before charging ahead. :-)
#2
Yeah, the form should correspond to CNF. I did not want to mention the conjunctive normal form, because boolean logic is a bit far-fetched, but what the heck! No worries. :-)
From the perspective of flexibility, a full reproduction of SQLs abilities would be best. That is, as you pointed out, a little more complicated as the current AND-conjunction of arguments. That's why I thought of the automism of bundling arguments of the same type, I think an AND-conjunction is of no use in this case.
If you want to go all out and implement arbitrary "conjunctive normal forms", I see two possibilities. The first is to change the whole GUI accordingly, which is a bit much for my taste. The second option which comes to my mind is some kind of composition instruction. If your had four arbitrary arguments you could state in a single line something like
( 1 | 2 ) + ( 3 | 4 )that your arguments shall be interpreted like
SELECT...
WHERE
(statement_1 = value_1 OR
statement_2 = value_2) AND
(statement_3 = value_3 OR
statement_4 = value_4)
That could keep the GUI as is but provide the whole flexibility.
#3
Did this make it into Views 2?
#4
I agree that this would be a very useful feature and would like to see it be a part of views. I don't believe it should replace AND but allow users to choose.
#5
@lokisapocalypse: new features will go into 6.x first.
@catch not yet :p -- but from a conversation with merlinofchaos on IRC it looks like this feature will only happen after we can do the same thing with filters.
Here's a link to the filters issue help keep track of the status #118672: Adding sql ORing capability with filters
Also marking #334883: Extending the WHERE clause in argument handling code as duplicate of this issue.
#6
There's also http://drupal.org/project/views_or
and #291660: Port Views Or to Views 3
#7
@catch: right - Though sadly, from what merlinofchaos said at #3 in that issue and clarified today - Arguments didn't get the underlying structure filters did to support grouping :( so it looks like views_or module will only work for filters in the meantime but not yet for arguments.
Unless there's some other way to do this using arguments currently -- I mean, if you know about any provisional method for doing this? i'd love to try it out -- I don't have any other leads on ORing arguments :p
#8
+1
#9
@all
Hi! Never thought that this issue would live for so long... :o)
I had no time to try it out, but the views_or module descrition states that it can handle arguments as well.
Regards Henry
#10
Subscribe