75396 - Advanced query redesign.

Status: RESOLVED WORKSFORME

(Bugzilla :: Query/Bug List, enhancement)

Description

[Matthew Tuck [:CodeMachine]]

It would be nice to redesign advanced querying for BZ3, especially given that
the fields are not going to be fixed anyway.

In particular, the following are what I am thinking about us doing:

1.  More power.  This means you should be able to do all sorts of queries you
can't already.  Rather than doing a whole lot of work to support each, we should
automatically generate them from the types of the queries.  This will catch any
holes.

2.  List queries.  The current advanced query simple condition consists of 3
fields.  However this is not suitable for list fields and we run into all sorts
of hacky conditions.  While a normal field might look something like:

duplicates     >       3

a list field might look like:

operating-systems  all-values  in-set  { Win32, Mac }

or:

versions-reproduced  all-values  <   2.1

3.  More tailored queries.  Currently the condition (second) field contains a
whole lot of conditions that aren't suited to the field.  How does case
sensitivity in substrings apply to keywords?  What happens if you use "bug
number" with "none of the words"?  Ideally you should have to use the proper
operation with the field.  Other operations would either fail, or not be
presented in the first place.

Now there are two major considerations here.

Firstly, are the list queries implementable in SQL?  It is very likely they
would require subselects.  This might require emulating subselects on the MySQL
back end.

Secondly, there is a lot of use for the ability for the conditions to be in
different formats.  The conditions should tailor to the field, as should whether
there are 3 or 4 fields in total.

Now on some front ends this is not an issue, but on the HTML front end with no
javascript on it would still be nice to support this.  I suggest that we place a
list of fields at the top of the advanced query section, and when you click AND
or OR, it chooses that field, and the field field becomes static text.

Comment 1

[Matthew Tuck [:CodeMachine]]

Here's some rough cut notes:

Field Types vs. Operations
--------------------------

user name
	- account is enabled
	- account starts with str
	- account ends with str
	- account contains str
	- account matches regexp
	- account is in list
	- X (Account Age)?

unordered-values
	- value is in list

number/ordered-values/date/bug-num
	- value > X
	- value < X
	- value = X
	- value in range
	- value in set of numbers/ranges

text
	- text start with str
	- text ends with str
	- text contains str
	- text matches regexp
	- text is in set

List Field, Second Field
------------------------

no members of list match this operation
all members of list match this operation
some members of list match this operation
not all members of list match this operation
only one member of list matches this operation

"Fields" That Might Arise From a Field Module
---------------------------------------------

allocations:
	my allocations -> number
	total allocations -> number

reporter:
	reporter account -> user name
	report date -> date
	report age -> number

resolver:
	resolver account -> user name
	resolve date -> date
	resolve age -> number

verifier:
	verifier account -> user name
	verify date -> date
	verify age -> number

closer:
	closer account -> user name
	close date -> date
	close age -> number

assignees:
	assignee accounts -> user name list

qa:
	qa accounts -> user name list

dependencies:
	depends -> bug list
	blocks -> bug list

related:
	related -> bug list

Comment 2

[Matthew Tuck [:CodeMachine]]

Rather than a list field being:

Versions-Reproduced  /  All-Values  /  <  /  2.1

it would probably be more user friendly as:

All  /  Versions-Reproduced  /  <  /  2.1

Comment 3

[Matthew Tuck [:CodeMachine]]

Note that what I listed as "duplicates < 3" should probably be something like
"duplicates number-vals-< 3" since duplicates should be the duplicate list.

Comments and attachments should sit OK within this four value system since they
can be considered multi-valued fields.

Comment 4

[Dave Miller [:justdave]]

The Bugzilla 3 component is going away.  We're going to depend on the Milestones 
for this.  At the time this component was created, we didn't have milestones for 
Bugzilla.

Comment 5

[Hixie (not reading bugmail)]

Bailing on Bugzilla 3.0 due to too many other commitments.

Comment 6

[Max Kanat-Alexander]

Mostly nowadays this is WFM. The only part of it that wouldn't be WFM would be writing queries in text, which is bug 72976.