Re: ANNOUNCE: Beagle 0.3.2

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