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

merlinofchaos’s picture

FYI 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. =)

Alice Heaton’s picture

@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. some modules do several add_where, expecting the operator to be 'AND' (the default views_handler_filter_numeric for instance).
  2. some modules create their own groups (the date module for instance)
  3. some modules use INNER joins (taxonomy module for instance)

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...

merlinofchaos’s picture

How 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.

Alice Heaton’s picture

How does the INNER join mess up the OR clauses?

My 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 :

Taxonomy Term Id = Carrot
 OR
Published Date = now

This will generate the following query :

SELECT node.nid AS nid
FROM node node 
INNER JOIN term_node term_node ON node.vid = term_node.vid
WHERE (term_node.tid = 64) OR 
             (node.created = ***CURRENT_TIME***+0)

So this will return :

  • Nodes that have the taxonomy term carrot
  • Nodes that have a publish date of NOW, and have an entry in the term_node table (regardless of what that entry is)

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 :

SELECT node.nid AS nid
FROM node node 
LEFT JOIN term_node term_node ON node.vid = term_node.vid
WHERE (term_node.tid = 64 AND term_node.vid IS NOT NULL) OR 
             (node.created = ***CURRENT_TIME***+0)

(though in that particular case it's not needed, as term_node.tid = 64 implies term_node.vid IS NOT NULL)

vinoth.3v’s picture

Grouping?

This may be nice if there we can group multiple Conditions in AND OR NOT ??

Flying Drupalist’s picture

Has progress been made on this? Does Views 2 support OR now?

will_in_wi’s picture

I 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!

Alice Heaton’s picture

@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.

kenorb’s picture

+1

gunzip’s picture

subscribe

k3vin’s picture

+1

gpk’s picture

For reference, the active issue for adding this functionality to Views is #118672: Adding sql ORing capability with filters.

farald’s picture

+1 Subscribe

abqaria’s picture

+ 1

drewish’s picture

subscribing

Karlheinz’s picture

I 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.)

kinderpera’s picture

+1

rbrownell’s picture

+1

HnLn’s picture

subscribe

BenK’s picture

Subscribing

tomotomo’s picture

subscribe

picardo’s picture

subscribe

DarrellDuane’s picture

+1 Subscribe

mysterlune’s picture

Great work so far... subscribing.

felipe’s picture

Subscribing

gausarts’s picture

+1

sinasalek’s picture

+1 Subscribe

Murz’s picture

subscribe. Maybe will be better to create an issue on a Views2 module?

kenorb’s picture

neil.brown’s picture

Subscribe.

AntiNSA’s picture

subscribe

kenneth@fiil.eu’s picture

subscribe

my-family’s picture

subscribe

cels’s picture

subscribe

vthirteen’s picture

@Karlheinz #16 http://drupal.org/node/291660#comment-1800130

this sounds interesting. how would you do that?

Karlheinz’s picture

Whoops, 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:

x && (y || z) == (x && y) || (x && z)
x || (y && z) == (x || y) && (x || z)
(!x) && (!y) == !(x || y)
(!x) || (!y) == !(x && y)
x || y == !((!x) && (!y))
tomgf’s picture

Subscribe

jrabeemer’s picture

Title: Patch to views instead of a module? » Port Views Or to Views 3
Project: Views Or » Views (for Drupal 7)
Version: 6.x-1.x-dev » 6.x-3.x-dev
Component: Miscellaneous » Code
Category: task » feature
Priority: Critical » Normal
Issue tags: +OR

I think this needs to hit the Views 3.0 queue in order to get exposure. This is definitely a necessary feature. Rebasing...

jrabeemer’s picture

Status: Active » Closed (duplicate)

Saw a previous mention of a previous feature request. Marking dupe.

#118672: Adding sql ORing capability with filters

merlinofchaos’s picture

Yeah, 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.

gpk’s picture

Title: Port Views Or to Views 3 » Patch to views instead of a module?
Project: Views (for Drupal 7) » Views Or
Version: 6.x-3.x-dev » 6.x-1.x-dev
Category: feature » task

Agreed. Moving back to Views Or queue. Work now well underway at #118672: Adding sql ORing capability with filters so leaving status as dupe.

zdean’s picture

subscribe

Bastlynn’s picture

Title: Patch to views instead of a module? » Patch to views instead of a module?

subscribing

webel’s picture

Subscribe

that0n3guy’s picture

sub...

kenorb’s picture

It's done in Views 3.x now, so nothing to subscribe.

that0n3guy’s picture

Ahh, good to know :)

I guess I need to see how stable 3.x is then.

Harry Slaughter’s picture

++

dkinzer’s picture

++

codevoice’s picture

+1