Boolean Chart Redesign

[Bernd Groh]

David Marshall wrote:
>
> On 7/19/10 6:42 PM, "Bernd Groh" <bgroh at redhat.com> wrote:
>
>
>   
>>>   
>>>       
>> Charts inside charts? To be honest, I'd much prefer it if we did away
>> with this entire new chart thing. If you allow the use of parentheses,
>> and you apply logical precedence to your operators NOT, AND and OR, you
>> don't need any new charts, neither AND nor OR, as you'll be able to
>> express everything within a single chart. I'd much rather formulate the
>> entire query within a single chart, than using multiple charts in
>> multiple dimensions and having to consider nesting charts within charts.
>> But maybe that's just me? As to everything above the boolean charts, I
>> think the entire logic of the advanced search page implies AND with
>> respect to each of the sub-components. This should still apply. Whatever
>> is above the boolean charts, using the current logic, AND the entirety
>> of the one boolean chart. And in my opinion, there should only be one
>> boolean chart, and logic rules should apply.
>>
>>     
>
> The predicate of an SQL query is a tree[*].  Boolean charts are an
> expression of trees that can be composed in the advanced search UI in a way
> that is easy to write in a URL.  As a result, as Max has pointed out, there
> are some trees that cannot be expressed with Boolean charts as they are now
> implemented.
>   

Plus, of course, there are certain rules of logic that cannot really be 
applied. In other words, it isn't really a boolean chart, it's a 
pseudo-boolean chart. To me, if there's anything to be called boolean, 
I'd firstly want it to be boolean, rather than think about how it can be 
written in a URL to construct an SQL query from it. If I predominantly 
think about how I can write it in a URL in order to express trees, which 
are then used to create my SQL, how then do I go about getting boolean 
back into the Boolean charts? And I guess that's my main question.

> If we want arbitrarily complex queries, we must determine how to express the
> resulting trees in a URL.
>   

If that's my predominant focus, then yes, I believe that's right. But 
I'm still wondering whether we should design everything up to the URL, 
and, as such, the UI, around how we need to query in terms of SQL.

That said, as long as there is an option to pass in a boolean string, 
which is fully understood in terms of logic (and not that pseudo-logic 
the Boolean charts are using), then I think that's absolutely 
sufficient. Then everyone who wants to post a logic query can simply use 
that method, irrespective of the UI, or the API backend.

> If we choose to express the queries with parentheses and such, then we're
> not really using the chart concept anymore - we're just passing a stream of
> tokens that Search.pm will evaluate.  That's OK, actually - no one should
> really care how the tree is represented in a URL.
>   

Completely agree. Though I believe people indeed care how they can use 
the URL in order to query bugzilla. I know a lot of people who don't use 
the UI, but use the URL directly (me included), and for these people, 
the easier they can represent a boolean string, the easier it is. But 
that, as said, can be supported differently, it doesn't have to be 
reflected in the UI or the API backend.

Cheers,
Bernd

> [*] A brief discussion of predicate trees
>
> The simplest tree is just an atomic predicate, such as "product = 'foo'" or
> "bug_status IN ('NEW', 'REOPENED')".  Such a tree has only its root node,
> the atomic predicate.
>
> The next simplest is a negated atomic predicate.  This tree is a NOT node
> with its one atomic child.
>
> Next, of course, comes AND/OR nodes, with two or more subtrees.
>
> These trees have some interesting properties, but I will not bore you with
> tedious detail.
>
> I currently use these trees for putting Boolean charts into a data structure
> and then express them in SQL.  I have interesting ideas about evaluating the
> trees with methods other than the database, caching the results of the
> evaluation of some nodes, and so on.
>
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=bgroh@redhat.com>
>