[Koha-bugs] [Bug 10542] QueryParser + OpacSuppression doesn't allow search in 'all libraries'

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10542

--- Comment #12 from David Cook <dcook at prosentient.com.au> ---
Hmm, now I'm unsure about my answer due to the order of operations...

Example from IndexData (http://www.indexdata.com/yaz/doc/tools.html#PQF)

@or "dylan" "zimmerman"

@and @or dylan zimmerman when

@and when @or dylan zimmerman

It seems like you always need to have your operators at the beginning...and
that it figures out the order on its own. 

In the 3rd case, not all the operators are at the beginning, but they are
before the "pair" of operands on which they're operating.

Here's my query that worked:

@not @or @or @or @attr 1=1016 @attr 5=1 @attr 4=6 "e" @attr 9=75 @attr 2=102
@attr 5=1 @attr 4=6 "e" @attr 9=20 @attr 2=102 @attr 5=1 @attr 4=6 "e" @attr
9=34 @attr 2=102 @attr 5=1 @attr 4=6 "e" @attr 1=9011 1

Yet...consider the following:

  prefixQuery("dinosaur");
    CCLQuery("dinosaur");

    prefixQuery("@and complete dinosaur");
    CCLQuery("complete and dinosaur");

    prefixQuery("@and complete @or dinosaur pterosaur");
    CCLQuery("complete and (dinosaur or pterosaur)");

    prefixQuery("@attr 1=7 0253333490");
    CCLQuery("isbn=0253333490");


Even these examples don't make sense but it's probably something like...

"e and not e or e or e or suppress=1"

Maybe... "e and not (e or e or e or suppress=1)"

Which...will hide the suppressed records...but it'll also kill those other "e"
subqueries...

-- 
You are receiving this mail because:
You are watching all bug changes.