koha-zebra
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mike Taylor
Subject: Re: [Koha-zebra] A few ZOOM::Package questions -- some Adam questions
Date: Wed, 22 Feb 2006 16:27:09 GMT

To expand on a couple of Seb's answers ...

> Date: Tue, 21 Feb 2006 10:27:03 -0500
> From: Sebastian Hammer <address@hidden>
> 
>> 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.

Either way will work "mechanically", so you have a choice to make.
That choice should be driven primarily by notion of what constitutes
an atomic transaction, semantically speaking, in your application.
For example, if you change an author-name in an authority record, and
also change the corresponding author fields in all your bibliographic
records, than that is semantically speaking a single operation (even
though it's implemented by updates to multiple records), so it should
all be a single transaction, i.e. don't call "commit" until you've
made all the changes.  A secondary concern is efficiency: in general,
it will (I think?  Adam?) be more efficient to do many updates
followed by a single commit, than to do many update-commit pairs.

>> 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.

It's certainly conventional to make a single connection and use that
for the whole application.  When connecting to a remote server (which
is of course the classic scenario for Z39.50) this is a _big_
efficiency win: for example, the old Library of Congress server used
to take about twenty times as long to do a connect-init-search
sequence as a single search.  However, in the case of a Zebra-enabled
Koha, you presumably run the Zebra on the same box as the client code,
so you should have no DNS lookup and negligible connection time; and
Zebra handles Init very quickly.  Still and all, Init is another
round-trip, so if you're going to be doing many searches, it's still
going to be noticably better to re-use the same connection for them
all instead of repeatedly tearing it down, remaking it and re-doing
the Init round-trip.

>>>> 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.

Oh, you can certainly do _that_.  Just reset the connection object's
"databaseName" option before each operation:

        $conn->option(databaseName => marcDB);
        # Do stuff in that the database of MARC records
        $conn->option(databaseName => dc);
        # Do stuff in that the database of Dublin Core records

>> BUT I think I understand now that the connection object only allows
>> a single connection at a time.

Yes; but connections are different from databases!

> 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.

... i.e. it implements a union catalogue.  That can be useful, but (if
I've understood you correctly) it's a _different_ useful thing from
the one you're asking about.

 _/|_    ___________________________________________________________________
/o ) \/  Mike Taylor  <address@hidden>  http://www.miketaylor.org.uk
)_v__/\  "Sure it stinks, but only a little stink; not the horrendous
         stench you might find in some other alleged ``science'' reports"
         -- Thomas R. Holtz, Jr. in a mellow mood





reply via email to

[Prev in Thread] Current Thread [Next in Thread]