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: Joshua Ferraro
Subject: Re: [Koha-devel] Zebra and Directory Structures
Date: Tue, 21 Nov 2006 10:23:57 -0800
User-agent: Mutt/1.5.9i

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
address@hidden |Full Demos at http://liblime.com/koha |1(888)KohaILS




reply via email to

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