[Koha-zebra] zebra extended services problem

Sebastian Hammer quinn at indexdata.com
Thu Jan 5 15:06:05 CET 2006


Mike Taylor wrote:

>>Date: Tue, 03 Jan 2006 14:45:51 +0100
>>From: Paul POULAIN <paul.poulain at free.fr>
>>
>>I begin to play with ZOOM::package and get some unclear (to me)
>>errors...
>>    
>>
>
>Hi, Paul, thanks for this message, let's see what we can clear up.
>
>  
>
>>>eval {
>>>	$Zconn = new ZOOM::Connection('localhost','2100');
>>>};
>>>if ($@) {
>>>	print "Error ", $@->code()," : ",$@->message();"\n";
>>>}
>>>      
>>>
>
>First of all, you may find it useful to know that you can omit these
>explicit error-checks, at least for one-off command-line programs:
>Perl's default behaviour when an object is thrown (i.e. used as the
>argument to die()) is just to print it, and the ZOOM::Exception class
>renders itself quite nicely.  Of course, you'll still need to catch
>exceptions if you want to handle them intelligently, but if all you're
>doing it printing them, then there's no need.
>
>  
>
>>># first, drop Zebra DB
>>>eval {
>>>my $Zpackage = $Zconn->package();
>>>	$Zpackage->send("drop");
>>>};
>>>      
>>>
>
>Two problems here.  First, _what_ database do you want to drop?  You
>need to set its name into the XS package so that the server knows what
>you're requesting:
>	$Zpackage->option(databaseName => $dbname);
>
>Second, there is a known bug in the database-dropping code that
>corrupts the registers:
>	http://bugzilla.indexdata.dk/show_bug.cgi?id=447
>so please don't do that for now!  (I know it's lame; it'll get fixed.)
>
>  
>
>>>eval {
>>>	my $Zpackage = $Zconn->package();
>>>	$Zpackage->option(databaseName => 'Koha');
>>>	$Zpackage->send("create");
>>>};
>>>      
>>>
>
>That looks fine.
>
>  
>
>>>	$Zpackage->option(record => $record->as_usmarc);
>>>      
>>>
>>[...]
>>But now, I get a :
>>Error updating 10002 => Encoding failed
>>
>>I bet it's
>> > 	$Zpackage->option(record => $record->as_usmarc);
>>    
>>
>
>Once more, you win the prize!  (Three in 24 hours.  Good going.)
>
>You're correct, the problem is in the form of the record you're
>passing into Zebra.  I am sorry that it's not diagnosed more
>explicitly.
>
>  
>
>>that is not the correct option, but I don't know how code the MARC
>>record and transmit it to zebra !
>>    
>>
>
>Zebra update works with XML, so you'll need to translate the MARC
>record into MARCXML and send that.  (Seb, I don't know whether more
>configuration is required on the server side to let it understand
>what's happening?)
>  
>
I don't think so, but the annoying thing that may come as a surprise is 
that when records are ingested as MARCXML (using type grs.xml or 
grs.marcxml for ISO2709), this renders them in a different *internal* 
structure than we get when records are ingested in raw ISO2709. The 
reasons for this are historical.. Zebra predates MARCXML, so we 
originally had to make up our own internal structure for MARC... when 
MARCXML became established, we thought it would be better to try to 
follow that.

So the usmarc.abs example file that comes with Zebra doesn't work as a 
dummy example. The good news is that the marc21.abs example DOES work. 
This is a Library of Congress-approved template to provide Bath level-1 
searching on top of a MARC21 record (the LOC approved it 'cause it was 
made for them). The 'melm' directive was approved because xelm 
/datafield[@tag='245']/subfield[@code='a'] gets a little tiresome to 
write and to look at it, but the xelm directive does work too. At any 
rate, I think the marc21.abs example is much closer to what most people 
expect in terms of indexing and searching than the old usmarc.abs, so 
it's a better starting point.

--Sebastian

> _/|_	 ___________________________________________________________________
>/o ) \/  Mike Taylor  <mike at miketaylor.org.uk>  http://www.miketaylor.org.uk
>)_v__/\  Peer review is a lot like the USA.  The current implementation
>	 sucks, but the idea is still good and noble and worth fighting
>	 for.  And even the current implementation is way better than
>	 most of the alternatives.
>
>
>
>
>_______________________________________________
>Koha-zebra mailing list
>Koha-zebra at nongnu.org
>http://lists.nongnu.org/mailman/listinfo/koha-zebra
>
>  
>

-- 
Sebastian Hammer, Index Data
quinn at indexdata.com   www.indexdata.com
Ph: (603) 209-6853







More information about the Koha-zebra mailing list