[Yazlist] baffled by cql, or maybe rec.id

Mike Taylor mike at indexdata.com
Sun Mar 27 11:28:31 CEST 2011


On 26 March 2011 13:22, Larry E. Dixson <ldix at loc.gov> wrote:
> Enrico and Mike,
> Sorry that I didn't catch this sooner.  I didn't realize that you were
> attempting to use Boolean operators with the @attr 1=12 search against
> a Voyager database.  What you are seeing is a Voyager server
> implementation "issue".  You cannot use Booleans with an @attr 1=12
> search.  That index search has special "behavior' in Voyager.  Try
> your search without the OR and see if that corrects the problem.
>
> Below is a session against our Voyager database -- to demonstrate
> that the problem is present at LC as well.

But if that's the case, why did MY session against the LC server work correctly?

cartney:photos mike$ yaz-client z3950.loc.gov:7090/voyager
Connecting...OK.
Sent initrequest.
Connection accepted by v3 target.
ID     : 34
Name   : Voyager LMS - Z39.50 Server (YAZ Proxy)
Version: 2007.2.0/1.2.1.1
Options: search present
Elapsed: 0.423290
Z> querytype cql
Z> f rec.id=1001
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 0
records returned: 0
Elapsed: 0.165135
Z> f rec.id=1001 or rec.id=1002
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 1
records returned: 0
Elapsed: 0.179830
Z> f rec.id=1001 or rec.id=1002 or rec.id=1003
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 1
records returned: 0
Elapsed: 0.145695
Z> f rec.id=1001 or rec.id=1002 or rec.id=1003 or rec.id=1004
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 1
records returned: 0
Elapsed: 0.156986
Z> f rec.id=1001 or rec.id=1002 or rec.id=1003 or rec.id=1004 or rec.id=1005
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 2
records returned: 0
Elapsed: 0.197544
Z>
>
> Sorry that it took so long for the "fog" to lift for me.
> Larry
>
>
> Z> f @or @attr 1=9 2008272044 @attr 1=9 99040535    [LCCN OK]
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 2
>
> Z> f @or @attr 1=12 1214711 @attr 1=12 249547    [001 ID search]
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 10000
>
> Z> f @and @attr 1=12 1214711 @attr 1=12 249547
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 10000
>
> Z> f @not @attr 1=12 1214711 @attr 1=12 249547
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 6488
>
>
> Z> f @attr 1=12 1214711            [one at a time is OK]
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 1
>
> Z> f @attr 1=12 249547
> Sent searchRequest.
> Received SearchResponse.
> Search was a success.
> Number of hits: 1
>
>
> On Sat, 26 Mar 2011, Mike Taylor wrote:
>
>> On 26 March 2011 05:15, Enrico Silterra <es287 at cornell.edu> wrote:
>> > Mike, i'm the one who set up the yaz proxy that we are talking to --
>> > here is the log from the yaz proxy, and this what it says.
>> >
>> > 01:10:25-26/03 [log] 1301116203:9952 2 CQL: rec.id=1001 or rec.id=1002
>> > 01:10:25-26/03 [log] 1301116203:9952 2 Search RPN @attrset Bib-1 @or
>> > @attr 1=12 @attr 5=100 @attr 6=1 @attr 3=3 @attr 4=1 @attr 2=3 1001
>> > @attr 1=12 @attr 5=100 @attr 6=1 @attr 3=3 @attr 4=1 @attr 2=3 1002
>> > 01:10:25-26/03 [log] 1301116203:9952 2 Sending searchRequest to
>> > database.library.cornell.edu:7090 223 bytes
>> > 01:10:32-26/03 [log] 1301116203:9952 2 Receiving searchResponse from
>> > database.library.cornell.edu:7090 18 bytes
>> > 01:10:32-26/03 [log] 1301116203:9952 2 10000 hits
>> > 01:10:32-26/03 [log] 1301116203:9952 2 Sending searchResponse to client
>> > 01:10:32-26/03 [log] 1301116203:9952 2 Elapsed 7.535
>> >
>> > i'm not very good at reading the RPN -- how does that look?
>>
>> Well, it's a correct translation of an "or" between the two values
>> 1001 and 1002.  Without looking them up, I don't know what the other
>> attributes mean, but since they're the same in the case when you
>> search for only a single ID, I assume they're not the problem.
>>
>> What do you get when you use YAZ Client to submit that search, in it's
>> PQF form, directly to the Voyager system, bypassing the YAZ Proxy?
>>
>> -- Mike.
>>
>>
>>
>> >
>> > rick
>> >
>> > On Fri, Mar 25, 2011 at 8:40 PM, Mike Taylor <mike at indexdata.com> wrote:
>> >> On 26 March 2011 00:34, Enrico Silterra <es287 at cornell.edu> wrote:
>> >>> here is the interaction, connecting to yaz proxy,
>> >>> which connects to a voyager z39.50 server.
>> >>>
>> >>> yaz-client -a apdu.log lxxxxxx:9090/voyager
>> >>> Connecting...OK.
>> >>> Sent initrequest.
>> >>> Connection accepted by v3 target.
>> >>> ID     : 34
>> >>> Name   : Voyager LMS - Z39.50 Server (YAZ Proxy)
>> >>> Version: 2007.1.1/1.3.6
>> >>> Options: search present
>> >>> Elapsed: 1.674038
>> >>> Z> querytype cql
>> >>> Z>  f rec.id=1001 or rec.id=1002
>> >>> Sent searchRequest.
>> >>> Received SearchResponse.
>> >>> Search was a success.
>> >>> Number of hits: 10000
>> >>> records returned: 0
>> >>> Elapsed: 7.503895
>> >>> Z> quit
>> >>>
>> >>>
>> >>> initRequest {
>> >>>   protocolVersion BITSTRING(len=1) 111
>> >>>   options BITSTRING(len=2) 11101001-1010001
>> >>>   preferredMessageSize 1048576
>> >>>   maximumRecordSize 1048576
>> >>>   implementationId '81'
>> >>>   implementationName 'YAZ'
>> >>>   implementationVersion '3.0.52 e687cb7eb87c841f0d1a374174d51d30371f2d97'
>> >>> }
>> >>> initResponse {
>> >>>   protocolVersion BITSTRING(len=1) 111
>> >>>   options BITSTRING(len=1) 11
>> >>>   preferredMessageSize 32768
>> >>>   maximumRecordSize 1048576
>> >>>   result TRUE
>> >>>   implementationId '34'
>> >>>   implementationName 'Voyager LMS - Z39.50 Server (YAZ Proxy)'
>> >>>   implementationVersion '2007.1.1/1.3.6'
>> >>> }
>> >>> searchRequest {
>> >>>   smallSetUpperBound 0
>> >>>   largeSetLowerBound 1
>> >>>   mediumSetPresentNumber 0
>> >>>   replaceIndicator TRUE
>> >>>   resultSetName 'default'
>> >>>   databaseNames {
>> >>>       'voyager'
>> >>>   }
>> >>>   {
>> >>>       query choice
>> >>>       type_104 {
>> >>>           OID: 1 2 840 10003 16 2
>> >>>           type_104 choice
>> >>>           {
>> >>>               'rec.id=1001 or rec.id=1002'
>> >>>           }
>> >>>       }
>> >>>   }
>> >>> }
>> >>> searchResponse {
>> >>>   resultCount 10000
>> >>>   numberOfRecordsReturned 0
>> >>>   nextResultSetPosition 1
>> >>>   searchStatus TRUE
>> >>>   presentStatus 0
>> >>> }
>> >>
>> >> That is extremely strange.  As you may know, the Library of Congress's
>> >> Z39.50 server is implemented by the same combination -- YAZ Proxy in
>> >> front of a Voyager catalogue -- and that works just fine, as you can
>> >> see in the transcript below.
>> >>
>> >> I can only think there must be some misconfiguration in the specific
>> >> YAZ Proxy or Voyager installation of the particular server you're
>> >> trying to work with.  Sorry if that's not very helpful.
>> >>
>> >> -- Mike.
>> >>
>> >>
>> >>
>> >>
>> >> cartney:photos mike$ yaz-client z3950.loc.gov:7090/voyager
>> >> Connecting...OK.
>> >> Sent initrequest.
>> >> Connection accepted by v3 target.
>> >> ID     : 34
>> >> Name   : Voyager LMS - Z39.50 Server (YAZ Proxy)
>> >> Version: 2007.2.0/1.2.1.1
>> >> Options: search present
>> >> Elapsed: 0.423290
>> >> Z> querytype cql
>> >> Z> f rec.id=1001
>> >> Sent searchRequest.
>> >> Received SearchResponse.
>> >> Search was a success.
>> >> Number of hits: 0
>> >> records returned: 0
>> >> Elapsed: 0.165135
>> >> Z> f rec.id=1001 or rec.id=1002
>> >> Sent searchRequest.
>> >> Received SearchResponse.
>> >> Search was a success.
>> >> Number of hits: 1
>> >> records returned: 0
>> >> Elapsed: 0.179830
>> >> Z> f rec.id=1001 or rec.id=1002 or rec.id=1003
>> >> Sent searchRequest.
>> >> Received SearchResponse.
>> >> Search was a success.
>> >> Number of hits: 1
>> >> records returned: 0
>> >> Elapsed: 0.145695
>> >> Z> f rec.id=1001 or rec.id=1002 or rec.id=1003 or rec.id=1004
>> >> Sent searchRequest.
>> >> Received SearchResponse.
>> >> Search was a success.
>> >> Number of hits: 1
>> >> records returned: 0
>> >> Elapsed: 0.156986
>> >> Z> f rec.id=1001 or rec.id=1002 or rec.id=1003 or rec.id=1004 or rec.id=1005
>> >> Sent searchRequest.
>> >> Received SearchResponse.
>> >> Search was a success.
>> >> Number of hits: 2
>> >> records returned: 0
>> >> Elapsed: 0.197544
>> >> Z>
>> >>
>> >
>> >
>> >
>> > --
>> > Enrico Silterra Software Engineer
>> > 501 Olin Library Cornell University Ithaca NY 14853
>> > Voice: 607-255-6851 Fax:     607-255-6110 E-mail: es287 at cornell.edu
>> > http://www.library.cornell.edu/dlit
>> > "Out of the crooked timber of humanity no straight thing was ever made"
>> > CONFIDENTIALITY NOTE
>> > The information transmitted, including attachments, is intended only
>> > for the person or entity to which it is addressed and may contain
>> > confidential and/or privileged material. Any review, retransmission,
>> > dissemination or other use of, or taking of any action in reliance
>> > upon, this information by persons or entities other than the intended
>> > recipient is prohibited. If you received this in error, please contact
>> > the sender and destroy any copies of this document.
>> >
>> >
>>
>> _______________________________________________
>> Yazlist mailing list
>> Yazlist at lists.indexdata.dk
>> http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist
>>
>
>
>
> _______________________________________________
> Yazlist mailing list
> Yazlist at lists.indexdata.dk
> http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yazlist
>
>



More information about the Yazlist mailing list