320717 - boolean chart don't respect boolean operators with negative request on flags

Status: RESOLVED DUPLICATE of bug 240398

(Bugzilla :: Query/Bug List, defect)

Description

[Florent Guiliani]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8) Gecko/20051111 Firefox/1.5

This bugs is not exactly the same than bug#181396 and bug#240398

The problem I want do deal with is a subset of the global problem when requesting multiple flags.

I want to deal only with negative request on multiple flags. For example: "find every bugs who doesn't contains block2.18+ or doesn't contains block2.20+". These requests are special because "negative flag request" are generating HAVING sql clauses.

Here it is: these HAVING causes are ANDed together whatever boolean operators were sized in the boolean chart. Here is the code from Search.pm:
    if (@having) {
        $query .= " HAVING " . join(" AND ", @having);
    }

So my request "find every bugs who doesn't contains block2.18+ or doesn't contains block2.20+" doesn't work because having clauses are ANDed and not ORed.

These types of requests can be handled correctly without breaking other things. I will upload a patch who try to correct this.


Reproducible: Always

Steps to Reproduce:
1.create two flags A and B
2.create a bug X and set A+
3.craete another bug Y and set B+
4.search bugs who doesn't contains A+ OR doesn't contains B+ with the boolean chart.
Actual Results:  
You don't get any of the X or Y bug.

Expected Results:  
X and Y would be included in the return list.

Comment 1

[Florent Guiliani]

Attachment: this patch try to reintroduce boolean order in HAVING sql clauses

While this solution doesn't resolve all the problem, it bring another piece of solution and solve a subset of the problem.

Comment 2

[Florent Guiliani]

(In reply to comment #1)
> Created an attachment (id=206244) [edit]
> this patch try to reintroduce boolean order in HAVING sql clauses
> 
> While this solution doesn't resolve all the problem, it bring another piece of
> solution and solve a subset of the problem.
> 

This patch apply against CVS version (18 December 2005).

Comment 3

[Max Kanat-Alexander]

Reporter: Make sure that you read the Contributor's Guide, so that you know how to get this patch reviewed:

  http://www.bugzilla.org/docs/contributor.html

Comment 4

[Joel Peshkin]

I'm not sure I'm very fond of doing a band-aid on this.  The right way for this to work (and a dramatically faster way) is to implement the queries on flags in the same manner as the queries of cclist members etc... where the SQL is generated within the context of the boolean charts.  This approach will fall apart when you try to do boolean charts involving a mixture of flags and non-flag items.

Comment 5

[Florent Guiliani]

(In reply to comment #4)
> This approach will fall
> apart when you try to do boolean charts involving a mixture of flags and
> non-flag items.
> 

The code already fall apart with a mixture of flags and non-flags items because whatever is reported in the boolean chart, the negative items on flags are ANDed in the HAVING.

This patch fix a subset of the problem. The requests with all negative flags items will work. At the moment they are not working.

I need to do some of these request so for me this patch is necessary. The requests are like "Find all bugs with one or more of flags A, B or C not set to +"

Comment 6

[Florent Guiliani]

(In reply to comment #4)
> The right way for this
> to work (and a dramatically faster way) is to implement the queries on flags in
> the same manner as the queries of cclist members etc... where the SQL is
> generated within the context of the boolean charts.

Yes for sure, but for the moment, without recode all of that, I'm trying to gets workarrounds.

Comment 7

[Joel Peshkin]

I understand.  I will ask the opinion of some others on the team regarding the merits of landing an interim partial fix versus the fully correct fix.

Comment 8

[Florent Guiliani]

Comment on attachment 206244 [details] [diff] [review]
this patch try to reintroduce boolean order in HAVING sql clauses

The patch is a little buged
I will upload a fixed patch just after this submit.

Comment 9

[Florent Guiliani]

Attachment: this patch try to reintroduce boolean order in HAVING sql clauses

This patch is obsoleting the first one.

Comment 10

[Joel Peshkin]

Comment on attachment 206307 [details] [diff] [review]
this patch try to reintroduce boolean order in HAVING sql clauses

See earlier comment.  The flag query needs to be rewrtten usign the same type of left join logic as everything else.

Comment 11

[Wayne Mery (:wsmwk)]

is this related to bug 240398?

Comment 12

[Joel Peshkin]

(In reply to comment #11)
> is this related to bug 240398?
> 

Yes.  It comes down to the fact that the query generator for Flags is all wrong and needs to be pretty much rewritten.