Boolean Chart Redesign

[Max Kanat-Alexander]

On 07/19/2010 05:16 PM, Benjamin Smedberg wrote:
> I'll note that as an "advanced charts user" there are some things that
> cannot be adequately expressed even with arbitrary AND/OR groupings.
> These mainly relate to queries on attachments or flags.

	Yes, the current implementation of Search.pm has serious problems with
one-to-many relationships. I recently wrote a regression test that tests
every combination of fields and operators for Search.pm, and there are
literally hundreds of broken combinations. (And if you start counting
groupings that break under AND/OR, there are probably millions of broken
combinations.) If you take a look at the log of the "xt MySQL" tinderbox
on the Bugzilla tinderbox tree, all of the tests marked TODO are somehow
broken.

	In general, searching attachments and flags does not work nearly as
well as it should, and that's something that I'm going to be fixing
regardless of what boolean chart design we end up using. I already have
a general idea of how I'm going to do the fix, but I have to do a bit
more refactoring first and then test some things out.

> I would really like some clarity on how limiters such as "attachment is
> obsolete" and "Flag requestee" and such are applied to attachment, bug
> flags, and attachment flags.

	Yeah, so would I. :-D

	Once I'm completely done with the Search.pm refactoring that's
underway, I plan to fully document (in public documentation, not just
code comments) how it all actually works.

> In addition, it would be really nice if we could have attachment
> queries, where the results link to particular attachments and list
> attachment metadata, instead of linking to bugs which you have to open
> and then look for the attachment which matched.

	Oh, that's an interesting thought. It's a possibility for the future.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.