[Top][All Lists]
[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