- Koha-devel - lists.koha-community.org

OPAC default stylesheet (owen 1st)
by Paul POULAIN 22 Nov '07

22 Nov '07

Hi all (and mainly owen) Owen has removed the default stylesheet in opac : before last night commits, if the opaccolorstylesheet syspref cas empty, it was the nice opac.css that was choosen by default. Shouldn't we reintroduce this behaviour, to avoid having a black and white opac by default? note : the sysprefs loaded at install stage don't contain opac.css, so the page is really black and white. -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

marc2dc (Dublin Core support)
by Paul POULAIN 21 Nov '07

21 Nov '07

Hello world, I just wanted to point that, afaik, the marc2dc tools one can find in cpan are only MARC21 compliant. They do silly things for UNIMARC. I've seen some commits about that, to let the user export or view the catalogue in Dublin Core format. This won't work at all for us. And we don't intend to make that work in the next weeks, as it's purely a new feature. Our wish would be to remove that feature for instance. Anyway, you MUST remember that before adding any new feature: check what it does for UNIMARC guys. PS : - isn't it time to create a stable and an unstable branch in git ? and deal only with bugfixes for stable (dc is, obviously, an improvement) - I ask for a chat meeting to discuss of next weeks plans. -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

Thoughts for discussion concerning muliti-dbms approach to koha
by Chris Nighswonger 20 Nov '07

20 Nov '07

Hi all, I have been putting some thought into the best approach for moving koha to a multi-dbms application and wanted to throw out a few of these thoughts hoping to get a discussion started with the aim to form a roadmap as this will most likely require some fairly major refactoring of code. (Not trying to "take charge" here, just trying to get momentum built up. :-) 1. This migration should probably begin by bringing all current SQL in koha into compliance as far as possible with ANSI SQL 1999 which it appears most rdbms support. (This may be debatable, I am not widely versed on dbms's) Note: I think that it will not be possible to implement pure ANSI SQL due to different approaches by different dbms's in handling table, constraint, etc. creation. But it should be possible to bring queries, inserts, etc. into some high level of compliance. 2. Once koha is ANSI SQL 1999 compliant, we need to/will have identified irreconcilable differences between dbms's koha would like to support (MySQL, PostgreSQL, and Oracle are currently on the table afaik). I *think* most of these issues will fall into one of two catagories: a. Differences in how the basic db structure is created. (ie. kohastructure.sql) It appears to me that different files will have to be maintained for each dbms structure. (ie. MySQL incorporates secondary keys while in PostgreSQL indexes must be used for the same effect, etc.) b. Differences which allow exploitation of a particular dbms strength. It may be that these types of things could be handled by separate modules for each supported dbms with selective includes based on the db_scheme setting koha-conf.xml or perhaps using stored proceedures/functions with a common nomenclature called from the code or <insert other approaches here>.... 3. Begin porting current code. Here, I suggest that the port be approached with the goal of ensuring that MySQL support *always* works as the port goes forward. This may be idealistic and/or unrealistic. When I did work on the webinstaller to add PostgreSQL, I set as my priority to not break the MySQL portion. This should permit a high level of compatibility with the current production installs on a forward moving basis. (ie. changes are fairly transparent) If multi-dbms mechanisms can be coded to work with MySQL, then they *should* work for the addition of any number 'x' dmbs as the appropriate ports are made for each. If it is modular enough, once the core code is ported, we should be able to add any dbms with minimal disturbances to the core. So.... thoughts, critiques, discussion, etc...? -- Chris Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.org

4 3

Advanced search Queries in Nozebra mode, via Nozebra table, queriying column named 'indexname', returning __RAW__ and failing in Search.pm
by Ignacio 20 Nov '07

20 Nov '07

Hello, this is Ignacio, new to the excellent Koha, prepared to put my hands on.. I'm working with koha-3.00.00.005 (debian etch, perl 5.8.8, ran in apache 2 via mod_perl) and after configuring searches in noZebra mode I'm having some problems to patch C4::Search to make it correctly parse and return advanced queries. I'm stuck with advanced search queries in Nozebra mode (via koha mysql's nozebra table), failing in Search.pm: The snippet of code that selects which value of column indexname for the advanced query in question is needed is given by: $left='title' if $left eq 'ti'; $left='author' if $left eq 'au'; $left='publisher' if $left eq 'pb'; $left='subject' if $left eq 'su'; $left='koha-Auth-Number' if $left eq 'an'; $left='keyword' if $left eq 'kw'; .. The problem seems to appear when you find that this column, in my mysql tables koha installation, seems single and only valued __RAW__, so searches result in no rows. Is there anyway to change this behaviour of avoiding this everlasting __RAW__ or is this the expected behavior and there is some other configuration/version problem? Thanks, Ignacio Javier

3 4

Daemon to look after the zebraqueue commit (from chris)
by Paul POULAIN 19 Nov '07

19 Nov '07

Hello world, I see a patch/commit from chris, about a script called zebraqueue_daemon, that seems to replace zebraqueue_start. Is it the case ? if yes, does it mean zebraqueue_start is now deprecated ? why does that have been done silently ? what about the new deps introduced ? -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

Possibility of defaulting biblio.datecreated to now()
by Chris Nighswonger 15 Nov '07

15 Nov '07

Hi all, Does anyone see any reason not to default biblio.datecreated to now()? -- Chris Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.org

2 2

items.ccode or items.itype ?
by Paul POULAIN 15 Nov '07

15 Nov '07

Hello world (and mainly liblimers) kados told me on the chat last week that the item-level circulation stuff relied on items.ccode field. I see this morning commits from Ryan, that speak of "further mods to change from ccode to itype at item-level itypes" Does it mean ccode won't be used anymore and the field name is in fact items.itype ? Is there something i've missed here ? -- Paul POULAIN BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

Re: [Koha-devel] do we really want postgres support NOW ?
by Joe Atzberger 14 Nov '07

14 Nov '07

> Is there truly such a big interest in PostgreSQL over MySQL compared to > Zebra over MySQL? > Zebra is run "along side" your database to generate and maintain indexing. Broadly speaking, I agree with Paul and Chris that "full support" for postgress (backed by robust testing) is unlikely to be available in 3.0, out of the box. --Joe Atzberger Systems Administrator, LibLime

1 0

commit "various authorities fixes" (from galen)
by Paul POULAIN 14 Nov '07

14 Nov '07

Hello world, I have some comment & thoughts about this commit : http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=commit;h=fa480ea4f3e9a8f9db… * 152 field for authority type is unused in marc21, so using it is harmless. But it's the correct field for unimarc, so I think we could accept it (as 1xx is the correct place imho) * why would be need to use summary only in UNIMARC ? The limits of the summary feature are the same in MARC21 & UNIMARC. And for full headings, it does not work 100% correctly in unimarc as well. So let it empty. That's what we say to our customers * The complete building of authority include some non translatable strings. It's not due to galen commit, but I think we will (in france) see this question thrown back to us quite soon... I don't know how we will solve it atm. knowing 2 and 3 users can choose to have something translated or something correct from a MARC pov. I know some customers that will prefer one, some prefering the other. -- Paul POULAIN, consultant senior BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

2 1

do we really want postgres support NOW ?
by Paul POULAIN 14 Nov '07

14 Nov '07

Hello again, We are a few days before a beta release of Koha 3.0 chris N. adds a lot of feature to support postgresSQL. which is undoubtfully a good feature. But do we want it now ? after rebasing this morning, all my koha setups were messed up : encoding was wrong again. Looking at last night commits, i've found a small error : $dbname instead of $db_driver in Context.pm This may have been unseen by the RM if test were not using non ascii char. The fix was trivial to do (patch sent to kados & chris) But I think we should NOT do so deep changes now. Maybe it's time for a 3.0-stable branch in git that will get only bugfixes ? -- Paul POULAIN, consultant senior BibLibre SARL Expert en Logiciels Libres pour l'info-doc Tel : 04 91 31 45 19

4 3