Deepak,
I think your goal is to gain something in speed, but most likely the
function query will be slower than the query without score computation (the
filter query) - this stems from the fact how the query is executed, but I
may, of course, be wrong. Would you mind sharing measurements you make?
Thanks,
roman
On Mon, Jul 22, 2013 at 10:54 AM, Yonik Seeley <yo...@lucidworks.com> wrote:
> function queries to the rescue!
>
> q={!func}def(query($a),query($b),query($c))
> a=field1:value1
> b=field2:value2
> c=field3:value3
>
> "def" or default function returns the value of the first argument that
> matches. It's named default because it's more commonly used like
> def(popularity,50) (return the value of the popularity field, or 50
> if the doc has no value for that field).
>
> -Yonik
> http://lucidworks.com
>
>
> On Sun, Jul 21, 2013 at 8:48 PM, Deepak Konidena <deepakk...@gmail.com>
> wrote:
> > I understand that lucene's AND (&&), OR (||) and NOT (!) operators are
> > shorthands for REQUIRED, OPTIONAL and EXCLUDE respectively, which is why
> > one can't treat them as boolean operators (adhering to boolean algebra).
> >
> > I have been trying to construct a simple OR expression, as follows
> >
> > q = +(field1:value1 OR field2:value2)
> >
> > with a match on either field1 or field2. But since the OR is merely an
> > optional, documents where both field1:value1 and field2:value2 are
> matched,
> > the query returns a score resulting in a match on both the clauses.
> >
> > How do I enforce short-circuiting in this context? In other words, how to
> > implement short-circuiting as in boolean algebra where an expression A
> || B
> > || C returns true if A is true without even looking into whether B or C
> > could be true.
> > -Deepak
>
