Hi, On 12/28/07, Arun Raghavan <[EMAIL PROTECTED]> wrote: > The query changes can be put off for the next release. Basically, > while parsing queries, we might encounter OR clauses (which are fine) > and AND clauses (which, I guess, are not) both of which might even be > nested (definitely not supported). Joe and I spoke about it while I > was first implementing the parser and decided to worry about this > later.
Right. Beagle doesn't support nesting of AND, only OR. I don't think there's any concrete reason why it couldn't support nesting of AND within OR, but it's a huge change to the underlying query code. There's a lot of work done to merge the logical outcomes of searching two Lucene indexes; I don't know how expensive or difficult it would be to support nested AND. > Right now, I'm parsing Xesam queries and translating them to text > searches when I should be using QueryParts. Yeah. Any programmatic use of the APIs beyond simple text searches should use QueryParts rather than doing things like AddText("mimetype:text/plain"). Parsing the text is slower and more error prone if the behavior changes. Adding general convenience APIs so you can do things like "Give me property 'mimetype' equal to 'text/plain'" would be nice; I suspect that people fall back on the text because it's easier than the alternative. > I think we might need to > extend QueryParts and the mapping to Lucene Queries to support this, > though I'm not sure if this is the correct approach. You mean nested ANDs? There's a lot more work than just QueryParts. ;) Joe _______________________________________________ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers