Re: ANNOUNCE: Beagle 0.3.2

["D Bera" <dbera web gmail com>]

> 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 now, I'm parsing Xesam queries and translating them to text
> searches when I should be using QueryParts. 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.

As Joe said in the other reply, supporting arbitrarily nested ANDs and
ORs will be quite a bit of work. This is partly because we do a
distributed search and cannot directly create one lucene query and
send it to lucene. Instead we dig deeper, query each atomic part and
then appropriately OR, AND or NOT it (depending on how it appeared in
the query).

Since every propositional formula can be written as a CNF (ANDs of
ORs), a temporary approach is to take any query with AND-OR clauses,
get the equivalent, possibly larger in size, CNF and then send that to
beagle. All on the client side. The CNF will be of exponential size in
the worst case, but it remains to be seen how bad it does in practice.

For adapter, I seriously recommend using the QueryParts; the query
syntax is rich enough to do a near-1-1 mapping from queryparts, but
there are some caveats and definite performance gains.

- dBera

-- 
-----------------------------------------------------
Debajyoti Bera @ http://dtecht.blogspot.com
beagle / KDE fan
Mandriva / Inspiron-1100 user