koha-devel
[Top][All Lists]
Advanced

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

Re: [Koha-devel] Zebra and Directory Structures


From: Paul POULAIN
Subject: Re: [Koha-devel] Zebra and Directory Structures
Date: Tue, 21 Nov 2006 15:52:43 +0100
User-agent: Thunderbird 1.5.0.7 (X11/20060915)

Joshua Ferraro a écrit :
Hey guys,

I'd like to propose that we reflect for a bit about how to structure the
zebra components within rel_3_0 before we diverge too much.

good proposal.

There are currently three zebra databases for a given rel_3_0 install, and it's likely there will be more in the future (if we have a metarecord
bibliographic for instance), but for now we have:

  biblios (biblio records)
  authorities (authorities records )
  public (for a publicly accessible Z39.50)

Each of these needs its own 'tab' directory, as well as registry
locations, etc (for the database files).

??? I thought public was just for a public access to biblios database & was not requiring more than a definition in the config file. Could you detail a little bit more what it is done for ?

We also have at least two MARC types to deal with, with more to follow
if our plans for world domination succeed :-): usmarc and unimarc.
Each flavor of MARC needs it's own tab files.

not only tab files, but also record.abs, ccl.properties, ...

I propose we create a standard for managing the zebra files as follows.

very good suggestion !

The installer creates one directory 'zebra' with the following contents:

$ ls zebra/
unimarc usmarc

then, in each of these we'll have:

$ ls zebra/usmarc/
authorities biblios public

within each of these we'll have in turn:
$ ls zebra/usmarc/biblios/
key  lock  recordDelete  register  shadow  specialUpdate  tab  tmp

why do we need to have this in CVS ? I suggest we could have a script that build all of these for you when setting up koha.

and, you know what ? I already did a large part of that script : misc/migration_tools/rebuild_zebra : it create all necessary directories, copies all needed files, all of this depending on your koha.xml file.
then it exports & reindex everything !

It has to be completed & tweaked but afaik it works correctly.

This way, if I have one server with three disks, I can have the
following distribution:

Filesystem      Mounted on
/dev/sda1       /
/dev/sda2       /koha/zebra/usmarc/biblios
/dev/sda3       /koha/zebra/usmarc/authorities

(ie, in this way, zebra biblios, authorities and mysql don't compete
for disk usage).

I'm almost OK with this structure, even if I think we don't need the usmarc level, just a library level, to be able to have X koha on the same server :
/koha/zebra/library1/biblios
/koha/zebra/library2/bilbios
/koha/zebra/library1/authorities
/koha/zebra/library2/authorities

I think it's more important to have everything for a given library in the same directory structure than having a disk dependant directory structure.

I also propose we attempt to keep unimarc and usmarc in as close sync as
possible, using the same naming conventions, etc., to make sure we
don't get confused. (I noticed that in the unimarc directory, there
are directories with capital letters as the first letter of the dir ...
which is different than in usmarc ... we should pick one method and
stick with it )

kados +++++++++++

I already have problems with Koha-number, Local-Number, Identifier-standard ...

All of the non-tab files (like koha.xml, ccl.properties, pqf.properties,
zebra-biblios.cfg, zebra-authorities.cfg, zebra-public.cfg should IMO
go into the koha etc directory,
mmm... for multiple setups, do will be use /etc/koha/setup1/... /etc/koha/setup2 /etc/koha/setup3 ... ? or will we prefer /home/zebra/library1/etc to have a single place for every library1 related things. I'me not found of one solution, so you'r will be mine, I just wanted to point the question.
but in CVS we should have:
misc/etc/usmarc/
misc/etc/unimarc/
because the files are different for each flavor of MARC. Or should we
store these config files in the tab dir?

mmm... I'm not sure, but I think we should have a different dir for all of them, not a record_for_unimarc.cfg as we have actually.

Finally, once we decide on a method, lets clean up CVS by deleting all
the extra directories and files (like zebraplugin and misc/zebra).
yep.

--
Paul POULAIN et Henri Damien LAURENT
Consultants indépendants
en logiciels libres et bibliothéconomie (http://www.koha-fr.org)
Tel : 04 91 31 45 19




reply via email to

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