On Tue, Nov 21, 2006 at 03:52:43PM +0100, Paul POULAIN wrote:
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 ? Well, it depends on your setup. Some libraries don't expose their holdings data to their public Z39.50 server, so in that case the data is dumped out of Zebra every night sans holdings, and the public Zebra database is different than biblios.
$ 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. I agree, no empty directories need to be in CVS, they can be created by the installer. But I still think we should still keep the CVS directory schema easy to understand.
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 like this idea ...
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 ... Identifier-standard is used by bib1 for the following:
Identifier-standard 1007 Standard numbers such as ISBN, ISSN, music publishers, numbers, CODEN, etc., that, are indexed together in many, online public-access catalogs. So it should never be used as the place for 090$c (biblionumber). Local-number however, is defined in bib1 as: Character string that uniquely identifies a record in a local system So it's exactly what 090$c is ... I propose that we use Local-number.
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. It's a good question ... I don't care either way as long as we standardize it.
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. OK, lets have misc/etc/usmarc and unimarc then. Maybe one general dir for files that they share? Can't the profilePath be made to override a preceeding directory in the path?
Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS