From: Barnett, J. <jef...@ya...> - 2008-09-11 14:53:05
|
I get a hundred or so messages like that (and a very peculiar display) when I display the holdings for http://yufind.library.yale.edu/yufind/Record/469523/Holdings . The staff view appears normal http://yufind.library.yale.edu/yufind/Record/469523/Details . As does the solr response <?xml version="1.0" encoding="UTF-8" ?> - <response> - <lst name="responseHeader"> <int name="status">0</int> <int name="QTime">0</int> </lst> - <result name="response" numFound="1" start="0"> - <doc> <str name="allfields">97647489 sc 80001045 2 3 0 1 R12300000 DNLM 0034-4338 460880 USPS (OCoLC)ocm05372932 (DNLM)R12300000(s) ABZ1705YL CLU CLU UCU BTI DLC NSD NST RCS OCL AIP NSD IUL NSD NST NSD NST DLC IUL CUS SYS OCL CUS OCLCQ lc nsdp e------ YUSS CB361 .R45 http://www.jstor.org/journals/00344338.html ELECTRONIC COPY Z 6207.R4 R393 940.2/1/005 Renaiss. q. Renaissance quarterly Renaissance quarterly. [New York] Renaissance Society of America. v. ill. 24 cm. Quarterly v. 20- spring 1967- Available on microfilm and microfiche from Kraus Reprint Co. Scanned images of back issues also available to subscribers of JSTOR via the World Wide Web. Some issues also available to subscribers via the World Wide Web. Issued by the Renaissance Society of America. Vols. 20-21, 1967-68. 1 v.; Vols. 22-23, 1969-70. 1 v.; Vols. 24-25, 1971-72. 1 v. "Beginning in 1975 issues of essays similar both in nature and extent [to: Studies in the Renaissance, ISSN 0081-8658] will be continued as the fourth issue of Renaissance quarterly." Renaissance Periodicals. Renaissance Society of America. Renaissance quarterly (Online) (DLC)sn 97023035 (OCoLC)37032182 Renaissance news 0277-903X (DLC) 51029088 (OCoLC)2251060 Studies in the Renaissance 0081-8658 (DLC) 54013109 (OCoLC)1623985 1975 CU-I CU-RivA DLC DeU IaAS InU KMK MH-CM MnU NcD NcRS ViU</str> - <arr name="author2"> <str>Renaissance Society of America.</str> </arr> - <arr name="author2Str"> <str>Renaissance Society of America.</str> </arr> <str name="callnumber">CB361.R45</str> <str name="callnumber-a">CB361</str> <str name="callnumber-first">C</str> - <arr name="collection"> <str>Catalog</str> </arr> - <arr name="dateSpan"> <str>v. 20- spring 1967-</str> </arr> - <arr name="format"> <str>Journal</str> </arr> <str name="fullrecord">LEADER 02117cas a2200505 45e0 001 469523 005 20040312131950.0 007 cr cnu-------- 007 cr unu-------- 008 790913c19679999nyuqr1p ob 0 a0eng d 010 $a 97647489 $zsc 80001045 012 $a2$b3$j0$m1 016 7 $aR12300000$2DNLM 022 0 $a0034-4338 032 $a460880$bUSPS 035 $a(OCoLC)ocm05372932 035 $a(DNLM)R12300000(s) 035 $9ABZ1705YL 040 $aCLU$cCLU$dUCU$dBTI$dDLC$dNSD$dNST$dRCS$dOCL$dAIP$dNSD$dIUL$dNSD$dNST$dNSD$dNST$dDLC$dIUL$dCUS$dSYS$dOCL$dCUS$dOCLCQ 042 $alc$ansdp 043 $ae------ 049 $aYUSS 050 00$aCB361$b.R45 051 $ahttp://www.jstor.org/journals/00344338.html$cELECTRONIC COPY 060 0 $aZ 6207.R4 R393 082 00$a940.2/1/005 210 0 $aRenaiss. q. 222 0$aRenaissance quarterly 245 00$aRenaissance quarterly. 260 $a[New York]$bRenaissance Society of America. 300 $av.$bill.$c24 cm. 310 $aQuarterly 362 0 $av. 20- spring 1967- 530 $aAvailable on microfilm and microfiche from Kraus Reprint Co. 530 $aScanned images of back issues also available to subscribers of JSTOR via the World Wide Web. 530 $aSome issues also available to subscribers via the World Wide Web. 550 $aIssued by the Renaissance Society of America. 555 $aVols. 20-21, 1967-68. 1 v.; Vols. 22-23, 1969-70. 1 v.; Vols. 24-25, 1971-72. 1 v. 580 $a"Beginning in 1975 issues of essays similar both in nature and extent [to: Studies in the Renaissance, ISSN 0081-8658] will be continued as the fourth issue of Renaissance quarterly." 650 0$aRenaissance$vPeriodicals. 710 2 $aRenaissance Society of America. 776 1 $tRenaissance quarterly (Online)$w(DLC)sn 97023035$w(OCoLC)37032182 780 00$tRenaissance news$x0277-903X$w(DLC) 51029088$w(OCoLC)2251060 780 15$tStudies in the Renaissance$x0081-8658$w(DLC) 54013109$w(OCoLC)1623985$g1975 850 $aCU-I$aCU-RivA$aDLC$aDeU$aIaAS$aInU$aKMK$aMH-CM$aMnU$aNcD$aNcRS$aViU</str> - <arr name="fulltopic"> <str>Renaissance Periodicals</str> </arr> <str name="id">469523</str> - <arr name="issn"> <str>0034-4338</str> </arr> - <arr name="langcode"> <str>eng</str> </arr> - <arr name="language"> <str>English</str> </arr> <str name="physical">ill.</str> <str name="publisher">Renaissance Society of America.</str> - <arr name="subtopic"> <str>Periodicals.</str> </arr> <str name="title">Renaissance quarterly</str> <str name="titleStr">Renaissance quarterly</str> <str name="title_short">Renaissance quarterly</str> - <arr name="topic"> <str>Renaissance</str> </arr> </doc> </result> </response> Here is the code (unchanged in trunk since r754 (by asnagy)) 262 private function _decode($text) 263 { 264 $matches = array(); 265 //if (!preg_match("/^(\d{5})/", $text, $matches)) { 266 // $errorMessage = File_MARC_Exception::formatError(File_MARC_Exception::$messages[File_MARC_Exception::ERROR_NONNUMERIC_LENGTH], array("record_length" => sub str($text, 0, 5))); 267 // throw new File_MARC_Exception($errorMessage, File_MARC_Exception::ERROR_NONNUMERIC_LENGTH); 268 //} 269 270 $marc = new File_MARC_Record(); 271 272 // Store record length 273 $record_length = $matches[1]; Three questions: 1) Why is it failing, not once but dozens of times for a single record? 2) Why was the preg_match test removed? 3) How is the value of $text transferred to $matches (or otherwise processed)? |
From: Wayne G. <ws...@wm...> - 2008-09-11 15:17:12
|
Which driver are you using? Most of the information on the holdings view gets pulled from the catalog, whereas the staff view uses info from the index which is why it looks correct in the staff view and the solr response. Wayne Barnett, Jeffrey wrote: > I get a hundred or so messages like that (and a very peculiar display) when I display the holdings for > http://yufind.library.yale.edu/yufind/Record/469523/Holdings . > > The staff view appears normal > http://yufind.library.yale.edu/yufind/Record/469523/Details . > > As does the solr response > > <?xml version="1.0" encoding="UTF-8" ?> > - <response> > - <lst name="responseHeader"> > <int name="status">0</int> > <int name="QTime">0</int> > </lst> > - <result name="response" numFound="1" start="0"> > - <doc> > <str name="allfields">97647489 sc 80001045 2 3 0 1 R12300000 DNLM 0034-4338 460880 USPS (OCoLC)ocm05372932 (DNLM)R12300000(s) ABZ1705YL CLU CLU UCU BTI DLC NSD NST RCS OCL AIP NSD IUL NSD NST NSD NST DLC IUL CUS SYS OCL CUS OCLCQ lc nsdp e------ YUSS CB361 .R45 http://www.jstor.org/journals/00344338.html ELECTRONIC COPY Z 6207.R4 R393 940.2/1/005 Renaiss. q. Renaissance quarterly Renaissance quarterly. [New York] Renaissance Society of America. v. ill. 24 cm. Quarterly v. 20- spring 1967- Available on microfilm and microfiche from Kraus Reprint Co. Scanned images of back issues also available to subscribers of JSTOR via the World Wide Web. Some issues also available to subscribers via the World Wide Web. Issued by the Renaissance Society of America. Vols. 20-21, 1967-68. 1 v.; Vols. 22-23, 1969-70. 1 v.; Vols. 24-25, 1971-72. 1 v. "Beginning in 1975 issues of essays similar both in nature and extent [to: Studies in the Renaissance, ISSN 0081-8658] will be continued as the f > ourth issue of Renaissance quarterly." Renaissance Periodicals. Renaissance Society of America. Renaissance quarterly (Online) (DLC)sn 97023035 (OCoLC)37032182 Renaissance news 0277-903X (DLC) 51029088 (OCoLC)2251060 Studies in the Renaissance 0081-8658 (DLC) 54013109 (OCoLC)1623985 1975 CU-I CU-RivA DLC DeU IaAS InU KMK MH-CM MnU NcD NcRS ViU</str> > - <arr name="author2"> > <str>Renaissance Society of America.</str> > </arr> > - <arr name="author2Str"> > <str>Renaissance Society of America.</str> > </arr> > <str name="callnumber">CB361.R45</str> > <str name="callnumber-a">CB361</str> > <str name="callnumber-first">C</str> > - <arr name="collection"> > <str>Catalog</str> > </arr> > - <arr name="dateSpan"> > <str>v. 20- spring 1967-</str> > </arr> > - <arr name="format"> > <str>Journal</str> > </arr> > <str name="fullrecord">LEADER 02117cas a2200505 45e0 001 469523 005 20040312131950.0 007 cr cnu-------- 007 cr unu-------- 008 790913c19679999nyuqr1p ob 0 a0eng d 010 $a 97647489 $zsc 80001045 012 $a2$b3$j0$m1 016 7 $aR12300000$2DNLM 022 0 $a0034-4338 032 $a460880$bUSPS 035 $a(OCoLC)ocm05372932 035 $a(DNLM)R12300000(s) 035 $9ABZ1705YL 040 $aCLU$cCLU$dUCU$dBTI$dDLC$dNSD$dNST$dRCS$dOCL$dAIP$dNSD$dIUL$dNSD$dNST$dNSD$dNST$dDLC$dIUL$dCUS$dSYS$dOCL$dCUS$dOCLCQ 042 $alc$ansdp 043 $ae------ 049 $aYUSS 050 00$aCB361$b.R45 051 $ahttp://www.jstor.org/journals/00344338.html$cELECTRONIC COPY 060 0 $aZ 6207.R4 R393 082 00$a940.2/1/005 210 0 $aRenaiss. q. 222 0$aRenaissance quarterly 245 00$aRenaissance quarterly. 260 $a[New York]$bRenaissance Society of America. 300 $av.$bill.$c24 cm. 310 $aQuarterly 362 0 $av. 20- spring 1967- 530 $aAvailable on microfilm and microfiche from Kraus Reprint Co. 530 $aScanned images of back issues also available to subscribers of JSTOR via the World Wide W > eb. 530 $aSome issues also available to subscribers via the World Wide Web. 550 $aIssued by the Renaissance Society of America. 555 $aVols. 20-21, 1967-68. 1 v.; Vols. 22-23, 1969-70. 1 v.; Vols. 24-25, 1971-72. 1 v. 580 $a"Beginning in 1975 issues of essays similar both in nature and extent [to: Studies in the Renaissance, ISSN 0081-8658] will be continued as the fourth issue of Renaissance quarterly." 650 0$aRenaissance$vPeriodicals. 710 2 $aRenaissance Society of America. 776 1 $tRenaissance quarterly (Online)$w(DLC)sn 97023035$w(OCoLC)37032182 780 00$tRenaissance news$x0277-903X$w(DLC) 51029088$w(OCoLC)2251060 780 15$tStudies in the Renaissance$x0081-8658$w(DLC) 54013109$w(OCoLC)1623985$g1975 850 $aCU-I$aCU-RivA$aDLC$aDeU$aIaAS$aInU$aKMK$aMH-CM$aMnU$aNcD$aNcRS$aViU</str> > - <arr name="fulltopic"> > <str>Renaissance Periodicals</str> > </arr> > <str name="id">469523</str> > - <arr name="issn"> > <str>0034-4338</str> > </arr> > - <arr name="langcode"> > <str>eng</str> > </arr> > - <arr name="language"> > <str>English</str> > </arr> > <str name="physical">ill.</str> > <str name="publisher">Renaissance Society of America.</str> > - <arr name="subtopic"> > <str>Periodicals.</str> > </arr> > <str name="title">Renaissance quarterly</str> > <str name="titleStr">Renaissance quarterly</str> > <str name="title_short">Renaissance quarterly</str> > - <arr name="topic"> > <str>Renaissance</str> > </arr> > </doc> > </result> > </response> > > Here is the code (unchanged in trunk since r754 (by asnagy)) > > 262 private function _decode($text) > 263 { > 264 $matches = array(); > 265 //if (!preg_match("/^(\d{5})/", $text, $matches)) { > 266 // $errorMessage = File_MARC_Exception::formatError(File_MARC_Exception::$messages[File_MARC_Exception::ERROR_NONNUMERIC_LENGTH], array("record_length" => sub > str($text, 0, 5))); > 267 // throw new File_MARC_Exception($errorMessage, File_MARC_Exception::ERROR_NONNUMERIC_LENGTH); > 268 //} > 269 > 270 $marc = new File_MARC_Record(); > 271 > 272 // Store record length > 273 $record_length = $matches[1]; > > Three questions: > > 1) Why is it failing, not once but dozens of times for a single record? > 2) Why was the preg_match test removed? > 3) How is the value of $text transferred to $matches (or otherwise processed)? > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech > > -- /** * Wayne Graham * Earl Gregg Swem Library * PO Box 8794 * Williamsburg, VA 23188 * 757.221.3112 * http://swem.wm.edu/blogs/waynegraham/ * http://www.liquidfoot.com */ |
From: Dan S. <de...@gm...> - 2008-09-12 03:29:35
|
2008/9/11 Barnett, Jeffrey <jef...@ya...>: <snip> > Here is the code (unchanged in trunk since r754 (by asnagy)) > > 262 private function _decode($text) > 263 { > 264 $matches = array(); > 265 //if (!preg_match("/^(\d{5})/", $text, $matches)) { > 266 // $errorMessage = File_MARC_Exception::formatError(File_MARC_Exception::$messages[File_MARC_Exception::ERROR_NONNUMERIC_LENGTH], array("record_length" => sub > str($text, 0, 5))); > 267 // throw new File_MARC_Exception($errorMessage, File_MARC_Exception::ERROR_NONNUMERIC_LENGTH); > 268 //} > 269 > 270 $marc = new File_MARC_Record(); > 271 > 272 // Store record length > 273 $record_length = $matches[1]; > > Three questions: > > 1) Why is it failing, not once but dozens of times for a single record? > 2) Why was the preg_match test removed? > 3) How is the value of $text transferred to $matches (or otherwise processed)? As one of the developers of the original File_MARC code over at http://pear.php.net, I think the answer to 2) is that it was an attempt to relax File_MARC's relatively strict format checking. Presumably Andrew has run into records that don't have a 5-digit length at the start of the leader, which would normally cause File_MARC to throw an exception, and he tried to disable that exception by commenting out those lines. In your case, the Details view appears to show that the first five characters of the leader are "a0211" - that's a corrupted MARC record. As you've noticed, though, the result of that approach is that the $matches array can never contain an element; the answer to 3) is that it's not. In some other places in File_MARC where it's possible to relax the parser without fatal results, I've replaced the exception by adding the error message to a warnings array in the record. In this case, a tolerable hack to avoid the warnings you're getting, and to have a meaningful value for $record_length, while not throwing exceptions for naughty MARC records that don't have a valid length in their leader, might be something like replacing line 273 with the following code: preg_match("/^(\d{5})/", $text, $matches); $record_length = 0; if (count(matches) > 1) { $record_length = $matches[1]; } else { $record_length = strlen($text); } Ideally, of course, one would have standards-compliant MARC records for input so that these kinds of hacks weren't necessary; trying to successfully process non-compliant MARC records through two different toolchains (SolrMARC/MARC4J and File_MARC) would almost demand clean MARC for input. Heh... "clean MARC". -- Dan Scott Laurentian University |
From: Barnett, J. <jef...@ya...> - 2008-09-12 13:37:22
|
Thanks Dan. I'll make your suggested change locally, and hope it eventually makes it into the trunk as well. I also mentioned the "clean MARC" suggestion to our catalogers. -----Original Message----- From: Dan Scott [mailto:de...@gm...] Sent: Thursday, September 11, 2008 11:30 PM To: Barnett, Jeffrey Cc: vuf...@li...; Andrew Nagy Subject: Re: [VuFind-Tech] Undefined offset: 1 in /usr/local/yulprog/yufind-r792/web/File/MARC.php on line 273 2008/9/11 Barnett, Jeffrey <jef...@ya...>: <snip> > Here is the code (unchanged in trunk since r754 (by asnagy)) > > 262 private function _decode($text) > 263 { > 264 $matches = array(); > 265 //if (!preg_match("/^(\d{5})/", $text, $matches)) { > 266 // $errorMessage = File_MARC_Exception::formatError(File_MARC_Exception::$messages[File_MARC_Exception::ERROR_NONNUMERIC_LENGTH], array("record_length" => sub > str($text, 0, 5))); > 267 // throw new File_MARC_Exception($errorMessage, File_MARC_Exception::ERROR_NONNUMERIC_LENGTH); > 268 //} > 269 > 270 $marc = new File_MARC_Record(); > 271 > 272 // Store record length > 273 $record_length = $matches[1]; > > Three questions: > > 1) Why is it failing, not once but dozens of times for a single record? > 2) Why was the preg_match test removed? > 3) How is the value of $text transferred to $matches (or otherwise processed)? As one of the developers of the original File_MARC code over at http://pear.php.net, I think the answer to 2) is that it was an attempt to relax File_MARC's relatively strict format checking. Presumably Andrew has run into records that don't have a 5-digit length at the start of the leader, which would normally cause File_MARC to throw an exception, and he tried to disable that exception by commenting out those lines. In your case, the Details view appears to show that the first five characters of the leader are "a0211" - that's a corrupted MARC record. As you've noticed, though, the result of that approach is that the $matches array can never contain an element; the answer to 3) is that it's not. In some other places in File_MARC where it's possible to relax the parser without fatal results, I've replaced the exception by adding the error message to a warnings array in the record. In this case, a tolerable hack to avoid the warnings you're getting, and to have a meaningful value for $record_length, while not throwing exceptions for naughty MARC records that don't have a valid length in their leader, might be something like replacing line 273 with the following code: preg_match("/^(\d{5})/", $text, $matches); $record_length = 0; if (count(matches) > 1) { $record_length = $matches[1]; } else { $record_length = strlen($text); } Ideally, of course, one would have standards-compliant MARC records for input so that these kinds of hacks weren't necessary; trying to successfully process non-compliant MARC records through two different toolchains (SolrMARC/MARC4J and File_MARC) would almost demand clean MARC for input. Heh... "clean MARC". -- Dan Scott Laurentian University |
From: Wayne G. <ws...@wm...> - 2008-09-12 14:15:07
|
Jeffrey, could you log this as a bug at http://sourceforge.net/tracker/?atid=969506&group_id=199442&func=browse ? One of the big issues we've run into on these projects (solrmarc and marc4j) are non-standards compliant MARC. Marc is very strict, and let's face it, over the last 50 years, record conversions haven't always gone nicely and just never got cleaned up (and sometimes local practices aren't always in line with the standard). Robert Haschart has been doing quite a bit of work on this issue in marc4j to attempt to "fix" these records and is working to get these changes into the main trunk of marc4j. We're actually using this version of marc4j in the Solrmarc trunk for indexing, which is quite forgiving of "bad" marc. The idea is to eventually log these records (or even write the bad marc) so they can be cleaned up. Also, could you send me some of these "bad" marc files? They're very useful in developing test cases to clean these up. Wayne Barnett, Jeffrey wrote: > Thanks Dan. I'll make your suggested change locally, and hope it eventually makes it into the trunk as well. I also mentioned the "clean MARC" suggestion to our catalogers. > > -----Original Message----- > From: Dan Scott [mailto:de...@gm...] > Sent: Thursday, September 11, 2008 11:30 PM > To: Barnett, Jeffrey > Cc: vuf...@li...; Andrew Nagy > Subject: Re: [VuFind-Tech] Undefined offset: 1 in /usr/local/yulprog/yufind-r792/web/File/MARC.php on line 273 > > 2008/9/11 Barnett, Jeffrey <jef...@ya...>: > <snip> > > >> Here is the code (unchanged in trunk since r754 (by asnagy)) >> >> 262 private function _decode($text) >> 263 { >> 264 $matches = array(); >> 265 //if (!preg_match("/^(\d{5})/", $text, $matches)) { >> 266 // $errorMessage = File_MARC_Exception::formatError(File_MARC_Exception::$messages[File_MARC_Exception::ERROR_NONNUMERIC_LENGTH], array("record_length" => sub >> str($text, 0, 5))); >> 267 // throw new File_MARC_Exception($errorMessage, File_MARC_Exception::ERROR_NONNUMERIC_LENGTH); >> 268 //} >> 269 >> 270 $marc = new File_MARC_Record(); >> 271 >> 272 // Store record length >> 273 $record_length = $matches[1]; >> >> Three questions: >> >> 1) Why is it failing, not once but dozens of times for a single record? >> 2) Why was the preg_match test removed? >> 3) How is the value of $text transferred to $matches (or otherwise processed)? >> > > As one of the developers of the original File_MARC code over at > http://pear.php.net, I think the answer to 2) is that it was an > attempt to relax File_MARC's relatively strict format checking. > Presumably Andrew has run into records that don't have a 5-digit > length at the start of the leader, which would normally cause > File_MARC to throw an exception, and he tried to disable that > exception by commenting out those lines. > > In your case, the Details view appears to show that the first five > characters of the leader are "a0211" - that's a corrupted MARC record. > > As you've noticed, though, the result of that approach is that the > $matches array can never contain an element; the answer to 3) is that > it's not. > > In some other places in File_MARC where it's possible to relax the > parser without fatal > results, I've replaced the exception by adding the error message to a > warnings array in the record. > > In this case, a tolerable hack to avoid the warnings you're getting, > and to have a meaningful value for $record_length, while not throwing > exceptions for naughty MARC records that don't have a valid length in > their leader, might be something like replacing line 273 with the > following code: > > preg_match("/^(\d{5})/", $text, $matches); > $record_length = 0; > if (count(matches) > 1) { > $record_length = $matches[1]; > } else { > $record_length = strlen($text); > } > > Ideally, of course, one would have standards-compliant MARC records > for input so that these kinds of hacks weren't necessary; trying to > successfully process non-compliant MARC records through two different > toolchains (SolrMARC/MARC4J and File_MARC) would almost demand clean > MARC for input. Heh... "clean MARC". > > -- > Dan Scott > Laurentian University > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech > > -- /** * Wayne Graham * Earl Gregg Swem Library * PO Box 8794 * Williamsburg, VA 23188 * 757.221.3112 * http://swem.wm.edu/blogs/waynegraham/ * http://www.liquidfoot.com */ |
From: Andrew N. <and...@vi...> - 2008-09-16 15:02:20
|
Jeffrey - I think this code is on an old revision. I would suggest updated and check if the error is still occuring. Andrew > -----Original Message----- > From: Barnett, Jeffrey [mailto:jef...@ya...] > Sent: Thursday, September 11, 2008 10:53 AM > To: vuf...@li...; Andrew Nagy > Subject: Undefined offset: 1 in /usr/local/yulprog/yufind- > r792/web/File/MARC.php on line 273 > > I get a hundred or so messages like that (and a very peculiar display) > when I display the holdings for > http://yufind.library.yale.edu/yufind/Record/469523/Holdings . > > The staff view appears normal > http://yufind.library.yale.edu/yufind/Record/469523/Details . > > As does the solr response > > <?xml version="1.0" encoding="UTF-8" ?> > - <response> > - <lst name="responseHeader"> > <int name="status">0</int> > <int name="QTime">0</int> > </lst> > - <result name="response" numFound="1" start="0"> > - <doc> > <str name="allfields">97647489 sc 80001045 2 3 0 1 R12300000 DNLM > 0034-4338 460880 USPS (OCoLC)ocm05372932 (DNLM)R12300000(s) ABZ1705YL > CLU CLU UCU BTI DLC NSD NST RCS OCL AIP NSD IUL NSD NST NSD NST DLC IUL > CUS SYS OCL CUS OCLCQ lc nsdp e------ YUSS CB361 .R45 > http://www.jstor.org/journals/00344338.html ELECTRONIC COPY Z 6207.R4 > R393 940.2/1/005 Renaiss. q. Renaissance quarterly Renaissance > quarterly. [New York] Renaissance Society of America. v. ill. 24 cm. > Quarterly v. 20- spring 1967- Available on microfilm and microfiche > from Kraus Reprint Co. Scanned images of back issues also available to > subscribers of JSTOR via the World Wide Web. Some issues also available > to subscribers via the World Wide Web. Issued by the Renaissance > Society of America. Vols. 20-21, 1967-68. 1 v.; Vols. 22-23, 1969-70. 1 > v.; Vols. 24-25, 1971-72. 1 v. "Beginning in 1975 issues of essays > similar both in nature and extent [to: Studies in the Renaissance, ISSN > 0081-8658] will be continued as the fourth issue of Renaissance > quarterly." Renaissance Periodicals. Renaissance Society of America. > Renaissance quarterly (Online) (DLC)sn 97023035 (OCoLC)37032182 > Renaissance news 0277-903X (DLC) 51029088 (OCoLC)2251060 Studies in the > Renaissance 0081-8658 (DLC) 54013109 (OCoLC)1623985 1975 CU-I CU-RivA > DLC DeU IaAS InU KMK MH-CM MnU NcD NcRS ViU</str> > - <arr name="author2"> > <str>Renaissance Society of America.</str> > </arr> > - <arr name="author2Str"> > <str>Renaissance Society of America.</str> > </arr> > <str name="callnumber">CB361.R45</str> > <str name="callnumber-a">CB361</str> > <str name="callnumber-first">C</str> > - <arr name="collection"> > <str>Catalog</str> > </arr> > - <arr name="dateSpan"> > <str>v. 20- spring 1967-</str> > </arr> > - <arr name="format"> > <str>Journal</str> > </arr> > <str name="fullrecord">LEADER 02117cas a2200505 45e0 001 469523 005 > 20040312131950.0 007 cr cnu-------- 007 cr unu-------- 008 > 790913c19679999nyuqr1p ob 0 a0eng d 010 $a 97647489 $zsc 80001045 012 > $a2$b3$j0$m1 016 7 $aR12300000$2DNLM 022 0 $a0034-4338 032 > $a460880$bUSPS 035 $a(OCoLC)ocm05372932 035 $a(DNLM)R12300000(s) 035 > $9ABZ1705YL 040 > $aCLU$cCLU$dUCU$dBTI$dDLC$dNSD$dNST$dRCS$dOCL$dAIP$dNSD$dIUL$dNSD$dNST$ > dNSD$dNST$dDLC$dIUL$dCUS$dSYS$dOCL$dCUS$dOCLCQ 042 $alc$ansdp 043 $ae-- > ---- 049 $aYUSS 050 00$aCB361$b.R45 051 > $ahttp://www.jstor.org/journals/00344338.html$cELECTRONIC COPY 060 0 > $aZ 6207.R4 R393 082 00$a940.2/1/005 210 0 $aRenaiss. q. 222 > 0$aRenaissance quarterly 245 00$aRenaissance quarterly. 260 $a[New > York]$bRenaissance Society of America. 300 $av.$bill.$c24 cm. 310 > $aQuarterly 362 0 $av. 20- spring 1967- 530 $aAvailable on microfilm > and microfiche from Kraus Reprint Co. 530 $aScanned images of back > issues also available to subscribers of JSTOR via the World Wide Web. > 530 $aSome issues also available to subscribers via the World Wide Web. > 550 $aIssued by the Renaissance Society of America. 555 $aVols. 20-21, > 1967-68. 1 v.; Vols. 22-23, 1969-70. 1 v.; Vols. 24-25, 1971-72. 1 v. > 580 $a"Beginning in 1975 issues of essays similar both in nature and > extent [to: Studies in the Renaissance, ISSN 0081-8658] will be > continued as the fourth issue of Renaissance quarterly." 650 > 0$aRenaissance$vPeriodicals. 710 2 $aRenaissance Society of America. > 776 1 $tRenaissance quarterly (Online)$w(DLC)sn > 97023035$w(OCoLC)37032182 780 00$tRenaissance news$x0277-903X$w(DLC) > 51029088$w(OCoLC)2251060 780 15$tStudies in the Renaissance$x0081- > 8658$w(DLC) 54013109$w(OCoLC)1623985$g1975 850 $aCU-I$aCU- > RivA$aDLC$aDeU$aIaAS$aInU$aKMK$aMH-CM$aMnU$aNcD$aNcRS$aViU</str> > - <arr name="fulltopic"> > <str>Renaissance Periodicals</str> > </arr> > <str name="id">469523</str> > - <arr name="issn"> > <str>0034-4338</str> > </arr> > - <arr name="langcode"> > <str>eng</str> > </arr> > - <arr name="language"> > <str>English</str> > </arr> > <str name="physical">ill.</str> > <str name="publisher">Renaissance Society of America.</str> > - <arr name="subtopic"> > <str>Periodicals.</str> > </arr> > <str name="title">Renaissance quarterly</str> > <str name="titleStr">Renaissance quarterly</str> > <str name="title_short">Renaissance quarterly</str> > - <arr name="topic"> > <str>Renaissance</str> > </arr> > </doc> > </result> > </response> > > Here is the code (unchanged in trunk since r754 (by asnagy)) > > 262 private function _decode($text) > 263 { > 264 $matches = array(); > 265 //if (!preg_match("/^(\d{5})/", $text, $matches)) { > 266 // $errorMessage = > File_MARC_Exception::formatError(File_MARC_Exception::$messages[File_MA > RC_Exception::ERROR_NONNUMERIC_LENGTH], array("record_length" => sub > str($text, 0, 5))); > 267 // throw new File_MARC_Exception($errorMessage, > File_MARC_Exception::ERROR_NONNUMERIC_LENGTH); > 268 //} > 269 > 270 $marc = new File_MARC_Record(); > 271 > 272 // Store record length > 273 $record_length = $matches[1]; > > Three questions: > > 1) Why is it failing, not once but dozens of times for a single record? > 2) Why was the preg_match test removed? > 3) How is the value of $text transferred to $matches (or otherwise > processed)? |
From: Barnett, J. <jef...@ya...> - 2008-09-16 17:29:52
|
It is old code, but there is nothing newer in the trunk. >From the original note: ---------------snip------------- > Here is the code (unchanged in trunk since r754 (by asnagy)) ---------------snip------------- Dan Scott (the original author) replied with what he calls a "tolerable hack" ---------------snip------------- In this case, a tolerable hack to avoid the warnings you're getting, and to have a meaningful value for $record_length, while not throwing exceptions for naughty MARC records that don't have a valid length in their leader, might be something like replacing line 273 with the following code: preg_match("/^(\d{5})/", $text, $matches); $record_length = 0; if (count(matches) > 1) { $record_length = $matches[1]; } else { $record_length = strlen($text); } ---------------snip-------------- which fixed the error msgs, but not the peculiar display. As for the "hundreds of msgs", turns out there were only 68, which was because we have 68 vols. of this journal. Finally, the recent (r1017) change to the display of holdings information by location (not to MARC.php) has cleared up the /Details screen. Bottom line, the problem is fixed for now at Yale, but you might want to incorporate Dan's hack into the trunk. -----Original Message----- From: Andrew Nagy [mailto:and...@vi...] Sent: Tuesday, September 16, 2008 11:02 AM To: Barnett, Jeffrey; vuf...@li... Subject: RE: Undefined offset: 1 in /usr/local/yulprog/yufind-r792/web/File/MARC.php on line 273 Jeffrey - I think this code is on an old revision. I would suggest updated and check if the error is still occuring. Andrew > -----Original Message----- > From: Barnett, Jeffrey [mailto:jef...@ya...] > Sent: Thursday, September 11, 2008 10:53 AM > To: vuf...@li...; Andrew Nagy > Subject: Undefined offset: 1 in /usr/local/yulprog/yufind- > r792/web/File/MARC.php on line 273 > > I get a hundred or so messages like that (and a very peculiar display) > when I display the holdings for > http://yufind.library.yale.edu/yufind/Record/469523/Holdings . > > The staff view appears normal > http://yufind.library.yale.edu/yufind/Record/469523/Details . > > As does the solr response > > <?xml version="1.0" encoding="UTF-8" ?> > - <response> > - <lst name="responseHeader"> > <int name="status">0</int> > <int name="QTime">0</int> > </lst> > - <result name="response" numFound="1" start="0"> > - <doc> > <str name="allfields">97647489 sc 80001045 2 3 0 1 R12300000 DNLM > 0034-4338 460880 USPS (OCoLC)ocm05372932 (DNLM)R12300000(s) ABZ1705YL > CLU CLU UCU BTI DLC NSD NST RCS OCL AIP NSD IUL NSD NST NSD NST DLC IUL > CUS SYS OCL CUS OCLCQ lc nsdp e------ YUSS CB361 .R45 > http://www.jstor.org/journals/00344338.html ELECTRONIC COPY Z 6207.R4 > R393 940.2/1/005 Renaiss. q. Renaissance quarterly Renaissance > quarterly. [New York] Renaissance Society of America. v. ill. 24 cm. > Quarterly v. 20- spring 1967- Available on microfilm and microfiche > from Kraus Reprint Co. Scanned images of back issues also available to > subscribers of JSTOR via the World Wide Web. Some issues also available > to subscribers via the World Wide Web. Issued by the Renaissance > Society of America. Vols. 20-21, 1967-68. 1 v.; Vols. 22-23, 1969-70. 1 > v.; Vols. 24-25, 1971-72. 1 v. "Beginning in 1975 issues of essays > similar both in nature and extent [to: Studies in the Renaissance, ISSN > 0081-8658] will be continued as the fourth issue of Renaissance > quarterly." Renaissance Periodicals. Renaissance Society of America. > Renaissance quarterly (Online) (DLC)sn 97023035 (OCoLC)37032182 > Renaissance news 0277-903X (DLC) 51029088 (OCoLC)2251060 Studies in the > Renaissance 0081-8658 (DLC) 54013109 (OCoLC)1623985 1975 CU-I CU-RivA > DLC DeU IaAS InU KMK MH-CM MnU NcD NcRS ViU</str> > - <arr name="author2"> > <str>Renaissance Society of America.</str> > </arr> > - <arr name="author2Str"> > <str>Renaissance Society of America.</str> > </arr> > <str name="callnumber">CB361.R45</str> > <str name="callnumber-a">CB361</str> > <str name="callnumber-first">C</str> > - <arr name="collection"> > <str>Catalog</str> > </arr> > - <arr name="dateSpan"> > <str>v. 20- spring 1967-</str> > </arr> > - <arr name="format"> > <str>Journal</str> > </arr> > <str name="fullrecord">LEADER 02117cas a2200505 45e0 001 469523 005 > 20040312131950.0 007 cr cnu-------- 007 cr unu-------- 008 > 790913c19679999nyuqr1p ob 0 a0eng d 010 $a 97647489 $zsc 80001045 012 > $a2$b3$j0$m1 016 7 $aR12300000$2DNLM 022 0 $a0034-4338 032 > $a460880$bUSPS 035 $a(OCoLC)ocm05372932 035 $a(DNLM)R12300000(s) 035 > $9ABZ1705YL 040 > $aCLU$cCLU$dUCU$dBTI$dDLC$dNSD$dNST$dRCS$dOCL$dAIP$dNSD$dIUL$dNSD$dNST$ > dNSD$dNST$dDLC$dIUL$dCUS$dSYS$dOCL$dCUS$dOCLCQ 042 $alc$ansdp 043 $ae-- > ---- 049 $aYUSS 050 00$aCB361$b.R45 051 > $ahttp://www.jstor.org/journals/00344338.html$cELECTRONIC COPY 060 0 > $aZ 6207.R4 R393 082 00$a940.2/1/005 210 0 $aRenaiss. q. 222 > 0$aRenaissance quarterly 245 00$aRenaissance quarterly. 260 $a[New > York]$bRenaissance Society of America. 300 $av.$bill.$c24 cm. 310 > $aQuarterly 362 0 $av. 20- spring 1967- 530 $aAvailable on microfilm > and microfiche from Kraus Reprint Co. 530 $aScanned images of back > issues also available to subscribers of JSTOR via the World Wide Web. > 530 $aSome issues also available to subscribers via the World Wide Web. > 550 $aIssued by the Renaissance Society of America. 555 $aVols. 20-21, > 1967-68. 1 v.; Vols. 22-23, 1969-70. 1 v.; Vols. 24-25, 1971-72. 1 v. > 580 $a"Beginning in 1975 issues of essays similar both in nature and > extent [to: Studies in the Renaissance, ISSN 0081-8658] will be > continued as the fourth issue of Renaissance quarterly." 650 > 0$aRenaissance$vPeriodicals. 710 2 $aRenaissance Society of America. > 776 1 $tRenaissance quarterly (Online)$w(DLC)sn > 97023035$w(OCoLC)37032182 780 00$tRenaissance news$x0277-903X$w(DLC) > 51029088$w(OCoLC)2251060 780 15$tStudies in the Renaissance$x0081- > 8658$w(DLC) 54013109$w(OCoLC)1623985$g1975 850 $aCU-I$aCU- > RivA$aDLC$aDeU$aIaAS$aInU$aKMK$aMH-CM$aMnU$aNcD$aNcRS$aViU</str> > - <arr name="fulltopic"> > <str>Renaissance Periodicals</str> > </arr> > <str name="id">469523</str> > - <arr name="issn"> > <str>0034-4338</str> > </arr> > - <arr name="langcode"> > <str>eng</str> > </arr> > - <arr name="language"> > <str>English</str> > </arr> > <str name="physical">ill.</str> > <str name="publisher">Renaissance Society of America.</str> > - <arr name="subtopic"> > <str>Periodicals.</str> > </arr> > <str name="title">Renaissance quarterly</str> > <str name="titleStr">Renaissance quarterly</str> > <str name="title_short">Renaissance quarterly</str> > - <arr name="topic"> > <str>Renaissance</str> > </arr> > </doc> > </result> > </response> > > Here is the code (unchanged in trunk since r754 (by asnagy)) > > 262 private function _decode($text) > 263 { > 264 $matches = array(); > 265 //if (!preg_match("/^(\d{5})/", $text, $matches)) { > 266 // $errorMessage = > File_MARC_Exception::formatError(File_MARC_Exception::$messages[File_MA > RC_Exception::ERROR_NONNUMERIC_LENGTH], array("record_length" => sub > str($text, 0, 5))); > 267 // throw new File_MARC_Exception($errorMessage, > File_MARC_Exception::ERROR_NONNUMERIC_LENGTH); > 268 //} > 269 > 270 $marc = new File_MARC_Record(); > 271 > 272 // Store record length > 273 $record_length = $matches[1]; > > Three questions: > > 1) Why is it failing, not once but dozens of times for a single record? > 2) Why was the preg_match test removed? > 3) How is the value of $text transferred to $matches (or otherwise > processed)? |
From: Barnett, J. <jef...@ya...> - 2009-01-09 20:59:40
|
I get to make the first post of the new year with good news. This is also reported on the vufind JIRA as VUFIND-21, but thought it worth adding to the list as well. I have a fix! The problem isn't really in "Record" at all, but in the getHolding() function in Voyager.php (We've know this for a while, but now I know what was causing the error). With Andrew's help back in November we isolated the trouble to the "Concat rows" step ... then thinking that there were some peculiar "short" record segments. It turns out the problem was simply forgetting that in addition to the need to order the selection by ITEM_SEQUENCE_NUMBER, it must also be ordered by MFHD_DATA.SEQNUM. While mfhd segments may initially appear in sequence by default physical order, a large record over time, with updates and changes will not. It is a one (half) line change, diff below: $ svn diff ./web/Drivers/Voyager.php Index: web/Drivers/Voyager.php =================================================================== --- web/Drivers/Voyager.php (revision 1139) +++ web/Drivers/Voyager.php (working copy) @@ -112,6 +140,7 @@ public function getHolding($id) { // Build SQL Statement +/* old statement (retained) */ $sql = "select ITEM_BARCODE.ITEM_BARCODE, ITEM.ITEM_ID, MFHD_DATA.RECORD_SEGMENT, MFHD_ITEM.ITEM_ENUM, ITEM.ON_RESERVE, ITEM.ITEM_SEQUENCE_NUMBER, ITEM_STATUS_DESC as status, LOCATION.LOCATION_DISPLAY_NAME as location, MFHD_MASTER.DISPLAY_CALL_NO as callnumber, CIRC_TRANSACTIONS.CURRENT_DUE_DATE as duedate " . "from $this->dbName.BIB_ITEM, $this->dbName.ITEM, $this->dbName.ITEM_STATUS_TYPE, $this->dbName.ITEM_STATUS, $this->dbName.LOCATION, $this->dbName.MFHD_ITEM, $this->dbName.MFHD_MASTER, $this->dbName.MFHD_DATA, $this->dbName.CIRC_TRANSACTIONS, $this->dbName.ITEM_BARCODE " . "where BIB_ITEM.BIB_ID = '$id' " . @@ -125,8 +154,44 @@ "and MFHD_MASTER.MFHD_ID = MFHD_ITEM.MFHD_ID " . "and MFHD_DATA.MFHD_ID = MFHD_ITEM.MFHD_ID " . "and MFHD_MASTER.SUPPRESS_IN_OPAC='N' " . - "order by ITEM.ITEM_SEQUENCE_NUMBER"; - + "order by ITEM.ITEM_SEQUENCE_NUMBER, mfhd_data.seqnum"; +/* End old statement */ You probably don't want my comments delimiting the change in the "old statement", but I don't think the diff would be valid if I just deleted them. Likewise the tablename and fieldname should be in uppercase, but I thought leaving them in lowercase make the change easier to recognise (and Oracle dosn't really care). -----Original Message----- From: vuf...@li... [mailto:vuf...@li...] On Behalf Of Barnett, Jeffrey Sent: Tuesday, September 16, 2008 1:29 PM To: Andrew Nagy; vuf...@li... Subject: Re: [VuFind-Tech] Undefined offset: 1 in /usr/local/yulprog/yufind-r792/web/File/MARC.php on line 273 It is old code, but there is nothing newer in the trunk. >From the original note: ---------------snip------------- > Here is the code (unchanged in trunk since r754 (by asnagy)) ---------------snip------------- Dan Scott (the original author) replied with what he calls a "tolerable hack" ---------------snip------------- In this case, a tolerable hack to avoid the warnings you're getting, and to have a meaningful value for $record_length, while not throwing exceptions for naughty MARC records that don't have a valid length in their leader, might be something like replacing line 273 with the following code: preg_match("/^(\d{5})/", $text, $matches); $record_length = 0; if (count(matches) > 1) { $record_length = $matches[1]; } else { $record_length = strlen($text); } ---------------snip-------------- which fixed the error msgs, but not the peculiar display. As for the "hundreds of msgs", turns out there were only 68, which was because we have 68 vols. of this journal. Finally, the recent (r1017) change to the display of holdings information by location (not to MARC.php) has cleared up the /Details screen. Bottom line, the problem is fixed for now at Yale, but you might want to incorporate Dan's hack into the trunk. -----Original Message----- From: Andrew Nagy [mailto:and...@vi...] Sent: Tuesday, September 16, 2008 11:02 AM To: Barnett, Jeffrey; vuf...@li... Subject: RE: Undefined offset: 1 in /usr/local/yulprog/yufind-r792/web/File/MARC.php on line 273 Jeffrey - I think this code is on an old revision. I would suggest updated and check if the error is still occuring. Andrew > -----Original Message----- > From: Barnett, Jeffrey [mailto:jef...@ya...] > Sent: Thursday, September 11, 2008 10:53 AM > To: vuf...@li...; Andrew Nagy > Subject: Undefined offset: 1 in /usr/local/yulprog/yufind- > r792/web/File/MARC.php on line 273 > > I get a hundred or so messages like that (and a very peculiar display) > when I display the holdings for > http://yufind.library.yale.edu/yufind/Record/469523/Holdings . > > The staff view appears normal > http://yufind.library.yale.edu/yufind/Record/469523/Details . > > As does the solr response > > <?xml version="1.0" encoding="UTF-8" ?> > - <response> > - <lst name="responseHeader"> > <int name="status">0</int> > <int name="QTime">0</int> > </lst> > - <result name="response" numFound="1" start="0"> > - <doc> > <str name="allfields">97647489 sc 80001045 2 3 0 1 R12300000 DNLM > 0034-4338 460880 USPS (OCoLC)ocm05372932 (DNLM)R12300000(s) ABZ1705YL > CLU CLU UCU BTI DLC NSD NST RCS OCL AIP NSD IUL NSD NST NSD NST DLC IUL > CUS SYS OCL CUS OCLCQ lc nsdp e------ YUSS CB361 .R45 > http://www.jstor.org/journals/00344338.html ELECTRONIC COPY Z 6207.R4 > R393 940.2/1/005 Renaiss. q. Renaissance quarterly Renaissance > quarterly. [New York] Renaissance Society of America. v. ill. 24 cm. > Quarterly v. 20- spring 1967- Available on microfilm and microfiche > from Kraus Reprint Co. Scanned images of back issues also available to > subscribers of JSTOR via the World Wide Web. Some issues also available > to subscribers via the World Wide Web. Issued by the Renaissance > Society of America. Vols. 20-21, 1967-68. 1 v.; Vols. 22-23, 1969-70. 1 > v.; Vols. 24-25, 1971-72. 1 v. "Beginning in 1975 issues of essays > similar both in nature and extent [to: Studies in the Renaissance, ISSN > 0081-8658] will be continued as the fourth issue of Renaissance > quarterly." Renaissance Periodicals. Renaissance Society of America. > Renaissance quarterly (Online) (DLC)sn 97023035 (OCoLC)37032182 > Renaissance news 0277-903X (DLC) 51029088 (OCoLC)2251060 Studies in the > Renaissance 0081-8658 (DLC) 54013109 (OCoLC)1623985 1975 CU-I CU-RivA > DLC DeU IaAS InU KMK MH-CM MnU NcD NcRS ViU</str> > - <arr name="author2"> > <str>Renaissance Society of America.</str> > </arr> > - <arr name="author2Str"> > <str>Renaissance Society of America.</str> > </arr> > <str name="callnumber">CB361.R45</str> > <str name="callnumber-a">CB361</str> > <str name="callnumber-first">C</str> > - <arr name="collection"> > <str>Catalog</str> > </arr> > - <arr name="dateSpan"> > <str>v. 20- spring 1967-</str> > </arr> > - <arr name="format"> > <str>Journal</str> > </arr> > <str name="fullrecord">LEADER 02117cas a2200505 45e0 001 469523 005 > 20040312131950.0 007 cr cnu-------- 007 cr unu-------- 008 > 790913c19679999nyuqr1p ob 0 a0eng d 010 $a 97647489 $zsc 80001045 012 > $a2$b3$j0$m1 016 7 $aR12300000$2DNLM 022 0 $a0034-4338 032 > $a460880$bUSPS 035 $a(OCoLC)ocm05372932 035 $a(DNLM)R12300000(s) 035 > $9ABZ1705YL 040 > $aCLU$cCLU$dUCU$dBTI$dDLC$dNSD$dNST$dRCS$dOCL$dAIP$dNSD$dIUL$dNSD$dNST$ > dNSD$dNST$dDLC$dIUL$dCUS$dSYS$dOCL$dCUS$dOCLCQ 042 $alc$ansdp 043 $ae-- > ---- 049 $aYUSS 050 00$aCB361$b.R45 051 > $ahttp://www.jstor.org/journals/00344338.html$cELECTRONIC COPY 060 0 > $aZ 6207.R4 R393 082 00$a940.2/1/005 210 0 $aRenaiss. q. 222 > 0$aRenaissance quarterly 245 00$aRenaissance quarterly. 260 $a[New > York]$bRenaissance Society of America. 300 $av.$bill.$c24 cm. 310 > $aQuarterly 362 0 $av. 20- spring 1967- 530 $aAvailable on microfilm > and microfiche from Kraus Reprint Co. 530 $aScanned images of back > issues also available to subscribers of JSTOR via the World Wide Web. > 530 $aSome issues also available to subscribers via the World Wide Web. > 550 $aIssued by the Renaissance Society of America. 555 $aVols. 20-21, > 1967-68. 1 v.; Vols. 22-23, 1969-70. 1 v.; Vols. 24-25, 1971-72. 1 v. > 580 $a"Beginning in 1975 issues of essays similar both in nature and > extent [to: Studies in the Renaissance, ISSN 0081-8658] will be > continued as the fourth issue of Renaissance quarterly." 650 > 0$aRenaissance$vPeriodicals. 710 2 $aRenaissance Society of America. > 776 1 $tRenaissance quarterly (Online)$w(DLC)sn > 97023035$w(OCoLC)37032182 780 00$tRenaissance news$x0277-903X$w(DLC) > 51029088$w(OCoLC)2251060 780 15$tStudies in the Renaissance$x0081- > 8658$w(DLC) 54013109$w(OCoLC)1623985$g1975 850 $aCU-I$aCU- > RivA$aDLC$aDeU$aIaAS$aInU$aKMK$aMH-CM$aMnU$aNcD$aNcRS$aViU</str> > - <arr name="fulltopic"> > <str>Renaissance Periodicals</str> > </arr> > <str name="id">469523</str> > - <arr name="issn"> > <str>0034-4338</str> > </arr> > - <arr name="langcode"> > <str>eng</str> > </arr> > - <arr name="language"> > <str>English</str> > </arr> > <str name="physical">ill.</str> > <str name="publisher">Renaissance Society of America.</str> > - <arr name="subtopic"> > <str>Periodicals.</str> > </arr> > <str name="title">Renaissance quarterly</str> > <str name="titleStr">Renaissance quarterly</str> > <str name="title_short">Renaissance quarterly</str> > - <arr name="topic"> > <str>Renaissance</str> > </arr> > </doc> > </result> > </response> > > Here is the code (unchanged in trunk since r754 (by asnagy)) > > 262 private function _decode($text) > 263 { > 264 $matches = array(); > 265 //if (!preg_match("/^(\d{5})/", $text, $matches)) { > 266 // $errorMessage = > File_MARC_Exception::formatError(File_MARC_Exception::$messages[File_MA > RC_Exception::ERROR_NONNUMERIC_LENGTH], array("record_length" => sub > str($text, 0, 5))); > 267 // throw new File_MARC_Exception($errorMessage, > File_MARC_Exception::ERROR_NONNUMERIC_LENGTH); > 268 //} > 269 > 270 $marc = new File_MARC_Record(); > 271 > 272 // Store record length > 273 $record_length = $matches[1]; > > Three questions: > > 1) Why is it failing, not once but dozens of times for a single record? > 2) Why was the preg_match test removed? > 3) How is the value of $text transferred to $matches (or otherwise > processed)? ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Vufind-tech mailing list Vuf...@li... https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Barnett, J. <jef...@ya...> - 2009-01-09 21:08:59
|
Note the bug dates back to r792, so the fix is applicable to users of vufind 0.8.2 as well as trunk builds. -----Original Message----- From: Barnett, Jeffrey Sent: Friday, January 09, 2009 4:00 PM To: Barnett, Jeffrey; Andrew Nagy; vuf...@li... Subject: RE: [VuFind-Tech] Undefined offset: 1 in /usr/local/yulprog/yufind-r792/web/File/MARC.php on line 273 FIXED! I get to make the first post of the new year with good news. This is also reported on the vufind JIRA as VUFIND-21, but thought it worth adding to the list as well. I have a fix! The problem isn't really in "Record" at all, but in the getHolding() function in Voyager.php (We've know this for a while, but now I know what was causing the error). With Andrew's help back in November we isolated the trouble to the "Concat rows" step ... then thinking that there were some peculiar "short" record segments. It turns out the problem was simply forgetting that in addition to the need to order the selection by ITEM_SEQUENCE_NUMBER, it must also be ordered by MFHD_DATA.SEQNUM. While mfhd segments may initially appear in sequence by default physical order, a large record over time, with updates and changes will not. It is a one (half) line change, diff below: $ svn diff ./web/Drivers/Voyager.php Index: web/Drivers/Voyager.php =================================================================== --- web/Drivers/Voyager.php (revision 1139) +++ web/Drivers/Voyager.php (working copy) @@ -112,6 +140,7 @@ public function getHolding($id) { // Build SQL Statement +/* old statement (retained) */ $sql = "select ITEM_BARCODE.ITEM_BARCODE, ITEM.ITEM_ID, MFHD_DATA.RECORD_SEGMENT, MFHD_ITEM.ITEM_ENUM, ITEM.ON_RESERVE, ITEM.ITEM_SEQUENCE_NUMBER, ITEM_STATUS_DESC as status, LOCATION.LOCATION_DISPLAY_NAME as location, MFHD_MASTER.DISPLAY_CALL_NO as callnumber, CIRC_TRANSACTIONS.CURRENT_DUE_DATE as duedate " . "from $this->dbName.BIB_ITEM, $this->dbName.ITEM, $this->dbName.ITEM_STATUS_TYPE, $this->dbName.ITEM_STATUS, $this->dbName.LOCATION, $this->dbName.MFHD_ITEM, $this->dbName.MFHD_MASTER, $this->dbName.MFHD_DATA, $this->dbName.CIRC_TRANSACTIONS, $this->dbName.ITEM_BARCODE " . "where BIB_ITEM.BIB_ID = '$id' " . @@ -125,8 +154,44 @@ "and MFHD_MASTER.MFHD_ID = MFHD_ITEM.MFHD_ID " . "and MFHD_DATA.MFHD_ID = MFHD_ITEM.MFHD_ID " . "and MFHD_MASTER.SUPPRESS_IN_OPAC='N' " . - "order by ITEM.ITEM_SEQUENCE_NUMBER"; - + "order by ITEM.ITEM_SEQUENCE_NUMBER, mfhd_data.seqnum"; +/* End old statement */ You probably don't want my comments delimiting the change in the "old statement", but I don't think the diff would be valid if I just deleted them. Likewise the tablename and fieldname should be in uppercase, but I thought leaving them in lowercase make the change easier to recognise (and Oracle dosn't really care). |