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

Larry E. Dixson ldix at loc.gov
Sat Mar 26 14:22:42 CET 2011


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.

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
> 




More information about the Yazlist mailing list