[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 #17 from David Cook <dcook at prosentient.com.au> ---
If I want to check my Koha query again...

--
TEST:

@not @or @or @or "a" "b" c" "e" "b" = 3 records("A","C","E")

((("a" or "b") or "c") or "e") and not "b"

--

Ok...now that we've got this basic concept down...let's try something more
advanced.

Let's consider the parsing logic again...

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

(In hindsight, the above example quite clearly illustrates how operators are
applied to operands. The tests helped clarify that though...at least in my mind
and hopefully for anyone else reading this who didn't understand before.)

So let's look at the grammar again
(http://www.indexdata.com/yaz/doc/tools.html#PQF):

"simple ::= result-set | term."

So a simple query may just be a single term like "A".

"complex ::= operator query-struct query-struct."

A complex query can have an operator and two query structures...but a query
structure is not the same thing as just a term.

"query-struct ::= attr-spec | simple | complex | '@term' term-type query"

A query structure can itself be a complex query! So we should be able to join
multiple complex queries together to form a new complex query.

--
TEST:

@or @or "a" "b" @or "c" "e" = 4 records ("A","B","C","E")

("a" or "b") or ("c" or "e")

--
TEST:

@not "test" @or "c" "e" = 3 records ("A","B","D")

("test") and not ("c" or "e")

--

So let's add some more complex data... I'm going to add "bull" to "B".

--
TEST:

@not @or "a" @or @and "b" "bull" "c" "a" = 2 records ("B","C")

("a" or ("b" and "bull") or "c") and not "a"

--
TEST:

@or "a" @or @and "b" "bull" "c" = 3 records ("A","B","C")

("a" or ("b" and "bull") or "c")

--

So something like the following is probably valid in CCL...

(kw,wrdl,rt=e or kw,wrdl,rt=e or kw,wrdl,rt=e or kw,wrdl,rt=e)

But I bet when it's parsed into RPN it is broken up into pairs like so:

(((kw,wrdl,rt=e or kw,wrdl,rt=e) or kw,wrdl,rt=e) or kw,wrdl,rt=e)

Because there has to be an order of operations...

For instance ("b" and "bull" or "c") would probably be parsed as (("b" and
"bull") or "c") rather than ("b" and ("bull" or "c")).

--
TEST:

(After using "querytype ccl2rpn" and "set_cclfile
/koha/etc/zebradb/ccl.properties" in yaz-client)

("b" and "bull" or "c") = 2 records ("B","C")

(("b" and "bull") or "c")

--
TEST:

("b" and ("bull" or "c")) = 1 record ("B")

------------

So...I'm sure that was more than anyone ever wanted to know about CCL and PQF
syntax. But...it proves that my solution will work.

Ideally, we should be adding OpacSuppression when the query is being built,
rather than after the fact. Ah, we do pass $query_type back from buildQuery.
While it's usually null, if it is a PQF query, it will say "pqf". That means it
won't be too hard to change our current code to work with QP.

At the moment, I'm inclined to agree with Galen about QueryParser not being
able to handle negation...although I'll have to look some more. 

That said, we could add OpacSuppression into the QP query building without
requiring it to parse it from a query we put in, so it might not matter too
much.

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