Patch to views instead of a module?

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

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

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.

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)

Grouping?

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

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

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!

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

+1

subscribe

+1

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

+1 Subscribe

+ 1

subscribing

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

+1

+1

subscribe

Subscribing

subscribe

subscribe

+1 Subscribe

Great work so far... subscribing.

Subscribing

+1

+1 Subscribe

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

There is one: #118672: Adding sql ORing capability with filters

Subscribe.

subscribe

subscribe

subscribe

subscribe

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

this sounds interesting. how would you do that?

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

Subscribe

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

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

#118672: Adding sql ORing capability with filters

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.

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

subscribe

subscribing

Subscribe

sub...

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

Ahh, good to know :)

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

++

++

+1