jakub-id
commented
1 month ago I believe https://github.com/indexdata/yaz/commit/8d030790a97d700720b893f589b3236726e1c24c6 caused this regression.
I think we should completely remove the check for e_ae->attributeSet which has previously always evaluated to true.
Sounds good @adamdickmeiss ?
Reported on yaz mailing list:
Hello,
we use the software "Metaproxy" from Indexdata (Vers 1.21.0) and the underlying library YAZ.
The new YAZ release 5.34.1 (we use the CentOS/RedHat 7 package from the indexdata repository) breaks searches with OCLC's "Sisis InfoGuide" origin.
Searches always result in 0 hits and in Metaproxy's logfile we always get error messages like:
01:47:12-12/07 1281 [log] FRONT ::ffff:130.73.102.123:542 542 0.001432 Search gvi ERROR 114 "4" USmarc 1+0 RPN @attrset Bib-1 @attr Bib-1 1=4 @attr Bib-1 2=3 @attr Bib-1 3=3 @attr Bib-1 4=2 @attr Bib-1 5=100 @attr Bib-1 6=1 patternmaking
OCLC's search requests look a little uncommon as they additionally have the attribute set name with each attribute. But as this is working for more than 20 years now, I assume this may be allowed by the Z39.60 specification.
You can simulate this behavior using yaz-client:
Z> find @attrset Bib-1 @attr Bib-1 1=1016 @attr Bib-1 2=3 @attr Bib-1 3=3 @attr Bib-1 4=2 @attr Bib-1 5=100 @attr Bib-1 6=1 patternmaking
As a work around we downgraded to yaz/liyaz5 5.34.0 which works fine.
Best Regards
Stefan Lohrum
APDU response trace:
SearchResponse-APDU : ReferenceId: z39origin-V5.0.1 ResultCount: 0 NumberOfRecordsReturned: 0 NextResultSetPosition: 0 SearchStatus: False ResultSetStatus: -- nicht belegt -- PresentStatus: -- nicht belegt -- Records : RecordType: RT_NonSurrDiagnostics Records : DiagnosticSetId: 1.2.840.10003.4.1 Condition: 114 AdditionalInfo_S : ProtocolVersionInForce: PVIF_Version2 AdditionalInfo_S: 4
APDU request trace:
SearchRequest-APDU : ReferenceId: z39origin-V5.0.1 SmallSetUpperBound: 0 LargeSetLowerBound: 1 MediumSetPresentNumber: 0 ReplaceIndicator: True ResultSetName: OST1760 DatabaseNames: k2 SmallSetElementNames : ElementSetType: ESTGeneric ElementSet_S: B MediumSetElementNames : ElementSetType: ESTGeneric ElementSet_S: B PreferredRecordSyntax: 1.2.840.10003.5.10 Query : QueryType: RpnQuery Query : AttributeSetId: 1.0.10163.3.1 RpnStructure : RpnStructureType: RST_RpnOperand RpnOperand : OperandType: OT_AttributePlusTerm AttributesPlusTerm : AttributeElement : AttributeSetId: 1.0.10163.3.1 AttributeType: 1 AttributeValue: 4 AttributeElement : AttributeSetId: 1.0.10163.3.1 AttributeType: 2 AttributeValue: 3 AttributeElement : AttributeSetId: 1.0.10163.3.1 AttributeType: 3 AttributeValue: 3 AttributeElement : AttributeSetId: 1.0.10163.3.1 AttributeType: 4 AttributeValue: 2 AttributeElement : AttributeSetId: 1.0.10163.3.1 AttributeType: 5 AttributeValue: 100 AttributeElement : AttributeSetId: 1.0.10163.3.1 AttributeType: 6 AttributeValue: 1 Term : TermType: TT_General General: patternmaking
This was announced via our RedHat Package Management on July 12th. automatically and since then the error has occurred. I don't have any indications of changes in the request in the ChangeLog Parsing found, but maybe something was smoothed out somewhere
-- Beste Grüße
Stefan Lohrum