Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This was a planned feature of Views 2 which merlinofchaos hasn't had time to write - however if someone was to submit a decent patch for it, he'd likely commit such a patch. A quick look at your module suggests some code style issues (and you say yourself it's experimental) - but still, better in the queue against views where it can be integrated with the main project.
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commentedFYI I'm interested in this feature. At this time it probably has to wait until after Views 2.0 to make it in, but I'd happily describe to you the UI I was looking for; a quick perusal of your code suggests you're using the underlying mechanisms that were meant for this.
The intended UI was meant to work like this:
Click on 'filters'; be presented with a select that sets the group-level conjunction (AND/OR), and the ability to add groups. Maybe add groups could also go on the rearrange page.
The rearrange page would use the tabledrag's hierarchy mechanism to let you simply drag filters from one group to another. This is a lot cleaner than using non-filter filters to separate groups. =)
Comment #2
Alice Heaton CreditAttribution: Alice Heaton commented@catch : Hey, thanks for your interest. I agree this should be part of Views ! I was planning to ask for at least some of the required API to be added, once this was stable. In the mean time, it's easier to work on a module, with CVS, bug tracking, etc. It's harder to develop/collaborate on a patch queue. I'll submit an issue in Views 2 that points back to this module (and this issue.)
The UI suggested by merlinofcahos is quite differet (and better!) than mine, so in it's current form, this wouldn't work as a patch.
@merlinofchaos : Yes, your UI is much nicer ! I'm quite busy right now, and as soon as I have some free time I promissed I would finish porting the nodereferrer module to D6. But once that is done, if this isn't yet in Views, I'll be really happy to help with it.
For information, this is some of the problems I have encountered :
1. and 2. means that it's impossible to change either the clause or the group operators without changing the effect of some of the queries. The only way I could see around that was to clear (and store) all groups between each alternative, then let the modules add whatever they want in the groups/where clauses. Once they have done it, I compact it all (all the groups and where clauses) into one where clause ; which I can then easily insert back.
For 3. I change the joins to LEFT joins, and add an extra condition in the where clauses. That works on the ones I've tested...
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedHow does the INNER join mess up the OR clauses?
I understand how 1 and 2 do; 1 can be fixed by making sure modules that do this add all their items together when possible. Item 2 is a little bit more difficult to deal with.
There's also the problem that all arguments add their filters in the magic group 0, which was something I did just to get past the problem of "Er, what group to use?" when I should've used $this->group like I did with filters so that arguments could also join in the OR grouping.
Also, I'm ok with an imperfect solution. We can identify filters that will not work with OR grouping and document them on the filter itself -- we could even use a flag that the UI can look at so that it's very automatic and consistent.
Comment #4
Alice Heaton CreditAttribution: Alice Heaton commentedMy understanding of an INNER join is that it only returns entries that have a matching record in both tables. This condition (that it must exist in both tables) applies to all parts of the query - regardless of the OR clauses.
Here is an example. Consider the following filters :
This will generate the following query :
So this will return :
However, this will not return nodes that have a published date of NOW, and have no entries in the term_node table.
I have deal with this problem by rewritting this query as :
(though in that particular case it's not needed, as term_node.tid = 64 implies term_node.vid IS NOT NULL)
Comment #5
vinoth.3v CreditAttribution: vinoth.3v commentedGrouping?
This may be nice if there we can group multiple Conditions in AND OR NOT ??
Comment #6
Flying Drupalist CreditAttribution: Flying Drupalist commentedHas progress been made on this? Does Views 2 support OR now?
Comment #7
will_in_wi CreditAttribution: will_in_wi commentedI am currently doing a project that needs this feature (or some horrible kitten-killing hack). What is the current status? Is this in views2 yet? Is the code here usable against the current release of views2? Does this work with nodereferrer?
Thanks!
Comment #8
Alice Heaton CreditAttribution: Alice Heaton commented@will_in_wi : I'm using Views Or on a production site with Views 2.1 and it works fine. As far as I know Views 2.2 didn't break backwards compatibility, so it should work fine.
I don't see why it wouldn't work with nodereferrer (I wrote the original D6 port of that one) but if it doesn't just report a bug and I'll have a look.
Comment #9
kenorb CreditAttribution: kenorb commented+1
Comment #10
gunzip CreditAttribution: gunzip commentedsubscribe
Comment #11
k3vin CreditAttribution: k3vin commented+1
Comment #12
gpk CreditAttribution: gpk commentedFor reference, the active issue for adding this functionality to Views is #118672: Adding sql ORing capability with filters.
Comment #13
farald CreditAttribution: farald commented+1 Subscribe
Comment #14
abqaria CreditAttribution: abqaria commented+ 1
Comment #15
drewish CreditAttribution: drewish commentedsubscribing
Comment #16
Karlheinz CreditAttribution: Karlheinz commentedI have a suggestion: Simply have a user-defined logical operator between every filter, and the option to negate that filter (i.e. a logical "not").
Since filters can be re-ordered, every combination of groupings could be achieved. (You'd have to be familiar with De Morgan's laws, but it could be done.)
Comment #17
kinderpera CreditAttribution: kinderpera commented+1
Comment #18
rbrownell+1
Comment #19
HnLn CreditAttribution: HnLn commentedsubscribe
Comment #20
BenK CreditAttribution: BenK commentedSubscribing
Comment #21
tomotomo CreditAttribution: tomotomo commentedsubscribe
Comment #22
picardo CreditAttribution: picardo commentedsubscribe
Comment #23
DarrellDuane CreditAttribution: DarrellDuane commented+1 Subscribe
Comment #24
mysterlune CreditAttribution: mysterlune commentedGreat work so far... subscribing.
Comment #25
felipe CreditAttribution: felipe commentedSubscribing
Comment #26
gausarts CreditAttribution: gausarts commented+1
Comment #27
sinasalek CreditAttribution: sinasalek commented+1 Subscribe
Comment #28
Murzsubscribe. Maybe will be better to create an issue on a Views2 module?
Comment #29
kenorb CreditAttribution: kenorb commentedThere is one: #118672: Adding sql ORing capability with filters
Comment #30
neil.brown CreditAttribution: neil.brown commentedSubscribe.
Comment #31
AntiNSA CreditAttribution: AntiNSA commentedsubscribe
Comment #32
kenneth@fiil.eu CreditAttribution: kenneth@fiil.eu commentedsubscribe
Comment #33
my-family CreditAttribution: my-family commentedsubscribe
Comment #34
cels CreditAttribution: cels commentedsubscribe
Comment #35
vthirteen CreditAttribution: vthirteen commented@Karlheinz #16 http://drupal.org/node/291660#comment-1800130
this sounds interesting. how would you do that?
Comment #36
Karlheinz CreditAttribution: Karlheinz commentedWhoops, you're right. It's been a while since I took logic. I thought between DeMorgan's Laws and the Distributivity Laws, there would be a way to get rid of groupings. But after working through it all, I realize I'm wrong.
For the curious, these are the laws I'm talking about:
Comment #37
tomgf CreditAttribution: tomgf commentedSubscribe
Comment #38
jrabeemer CreditAttribution: jrabeemer commentedI think this needs to hit the Views 3.0 queue in order to get exposure. This is definitely a necessary feature. Rebasing...
Comment #39
jrabeemer CreditAttribution: jrabeemer commentedSaw a previous mention of a previous feature request. Marking dupe.
#118672: Adding sql ORing capability with filters
Comment #40
merlinofchaos CreditAttribution: merlinofchaos commentedYeah, none of the folks who work on Views are responsible for the views_or module, so I'm not sure moving this to the Views queue was a good idea.
Comment #41
gpk CreditAttribution: gpk commentedAgreed. Moving back to Views Or queue. Work now well underway at #118672: Adding sql ORing capability with filters so leaving status as dupe.
Comment #42
zdean CreditAttribution: zdean commentedsubscribe
Comment #43
Bastlynn CreditAttribution: Bastlynn commentedsubscribing
Comment #44
webel CreditAttribution: webel commentedSubscribe
Comment #45
that0n3guy CreditAttribution: that0n3guy commentedsub...
Comment #46
kenorb CreditAttribution: kenorb commentedIt's done in Views 3.x now, so nothing to subscribe.
Comment #47
that0n3guy CreditAttribution: that0n3guy commentedAhh, good to know :)
I guess I need to see how stable 3.x is then.
Comment #48
Harry Slaughter++
Comment #49
dkinzer CreditAttribution: dkinzer commented++
Comment #50
codevoice CreditAttribution: codevoice commented+1