[Koha-zebra] A few ZOOM::Package questions -- some Adam questions

[Sebastian Hammer]

Joshua Ferraro wrote:

>On Mon, Feb 20, 2006 at 11:39:54AM +0000, Mike Taylor wrote:
>  
>
>>>What are the case scenerios where the 'commit' method would be
>>>useful?
>>>      
>>>
>>When using shadow registers in Zebra.
>>    
>>
>Which we definitely want to use. So do we 'commit' after 
>multiple update services or after each one?
>  
>
Either way should be fine.. all changes you've made prior to the commit 
become visible instantly when the commit process begins (because at that 
time, the UI begins to read the 'dirty' blocks of the index from the 
shadow files instead of from the main index.

>A somewhat related question is what you recommend for handling
>the $Zconn object. Our early proof-of-concept code had a new
>connection object being created and destroyed for every update
>action -- so ... should their be a single $Zconn for the whole
>system? or should we handle each incoming request as a separate
>connection (for search, update, create, drop (when available).
>One idea proposed was having our Context.pm module handle the
>connection in the same way we currently handle the dbh connection
>to MySQL ... but I know Z39.50 is a bit more stateful than MySQL...
>any suggestions?
>  
>
I'm not sure it makes much of a difference. If you do have multiple 
records you need to update, it should perform better if you can update 
them all at once.. but usually I guess you'll be doing single records.

>>>What is the xmlupdate method? :-)
>>>      
>>>
>>Don't know -- that's one for Adam to answer.
>>    
>>
>Cool ... hopefully he's cced on this...
>  
>
He is now, at least.

>>>We're trying to figure out when it would be useful (if ever) to use
>>>recordIdOpaque and/or recordIdName. The only reference to them I can
>>>find is here: http://www.indexdata.dk/zebra/NEWS where it says:
>>>
>>>"Allow Remote insert/delete/replace/update with record,
>>>recordIdNumber (sysno) and/or recordIdOpaque(user supplied record
>>>Id). If both IDs are omitted internal record ID match is assumed
>>>(recordId: - in zebra cfg)."
>>>
>>>Could someone provide a couple case scenerios where these would be
>>>used?
>>>      
>>>
>>I've not heard of "recordIdNumber" before, but I am guessing that it
>>just means "the unique ID of the record, as extracted from the record
>>itself using the rules specified in the Zebra configuration".  As you
>>know, every record in a Zebra database is identified by a, uh,
>>identifier.  That can either be drawn from the record itself (which
>>is probably what you want when adding MARC records that have IDs in
>>them), or you can specify an ID explicitly when you add the record.
>>
>>I don't know about case scenerios -- again, Adam would have a better
>>handle on that.
>>    
>>
>Ditto.
>  
>
I think chapter 5 should provide a reasonable explanation of the 
options. If you want to update records remotely, as you do, you will 
either need to explicitly provide an identifier, or have Zebra derive 
one from the record (i.e. a field 001 or similar).   

>>>When would it be useful to populate the databaseName option?
>>>      
>>>
>>Always, when creating or destroying a database.
>>
>>    
>>
>>>Isn't that already provided by the $conn object?
>>>      
>>>
>>No.  You might have a connection pointing at one database, and want to
>>create or destroy a different one.
>>
>>    
>>
>>>or can we connect to multiple databases in that object and then
>>>specify which one we want the specific package operation to be
>>>performed using that option?
>>>      
>>>
>>There's no "connect to multiple databases" functionality in ZOOM, no.
>>(What would such functionality mean?)
>>    
>>
>In my estimation, that would mean that you could connect to multiple 
>databases in the connection object, then specify which one you want
>to interact with for a given operation. One way this could be used would
>be for a Zebra installation that had two databases, one for full-text
>items in Dublin Core, and one using MARC records -- the MARC editor would
>first commit the full-text stuff to the DC db then the MARC records
>to the MARC db. But I think I understand now that the connection object
>only allows a single connection at a time.
>  
>
In Z39.50, you don't really 'connect' to a database... you connect to a 
target. In the wire protocol, the database name is provided for each 
search, update, etc. operation. It is meant as a convenience when you 
provide the database name at the yaz_connect stage, but the name is 
really just stored internally until a search is set off.

If you yaz_connect to multiple databases in yaz_connect (this can be 
done by separating the names with the '+' character in the ZOOM AAPI, 
then the server, if it supports multiple database names (Zebra does, 
AFAIK), will search across those logical database names.

>>>Finally, no mention is made of the record update 'syntax' option in
>>>the ZOOM documentation. Is it supported? if so, what are the valid
>>>values?
>>>      
>>>
>>Sorry -- again, I don't know.  Adam's yer man.
>>    
>>
>Ditto.
>  
>
TO my knowledgem, Zebra only suports updating via XML at the moment.

--Seb

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