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

about bug 4506 and branch new/awaiting_qa/analytical_records
by Zeno Tajoli 08 Dec '10

08 Dec '10

Hi katrin, I replay with an email because I have pronlem with iirc. But I send the mail also to koha-dev, to share information about this develop. The feature of analytical records is not activated by an system preference. But I will insert this check. I'm OK on your idea to use the 'controlrecord number' if you are part of a Union Cataloge. In a local sistem 'controlrecord number' = biblionumber We use alse itemrecord number because the link is an analytic link. >From a son without an item record (an chapter inside a book) to a father with a copy (a normal book with many chapters). What we (I, Amit and Savitra) are writing do 'ONLY' this link. Is not a generic tool to link records. Bye -- Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci qaunto tra AT con @)

1 0

1st solr meeting : logs
by LAURENT Henri-Damien 08 Dec '10

08 Dec '10

Hi, you can find there the logs of yesterday meeting. http://librarypolice.com/koha-meetings/2010/koha.2010-12-07-20.00.log.html We hope that people were not too much taken away by the form of the meeting. I talked too much. Please feel free to answer back and tell what you really expected, whether you wanted more technical details as of how we did or how to test, or what we still have to do and how we will do. We are disappointed by the fact that it was not that much interactive. We will try to make it clearer at the next meeting. Anyway, you can get the links from http://librarypolice.com/koha-meetings/2010/koha.2010-12-07-20.00.html to read more about what we did. The wip/solr branch is open. So you can use that. Please note nonetheless, as a side note, that we worked much more than what we were contractually mandated to do because we think that solr support is worth it for the whole community. Friendly -- Henri-Damien LAURENT BibLibre

1 0

Search Engine Changes : let's get some solr
by LAURENT Henri-Damien 07 Dec '10

07 Dec '10

Hi As you already read in Paul previous message about "BibLibre strategy for 3.4 and next version", we are growing, want be involved in the community as previously. Paul promised some POCs, here is one available. We also worked on Plack and support. We created a base of script to search for Memoryleaks. We'll demonstrate that later. zebra is fast and embeds native z3950 server. But it has also some major drawbacks we have to cope with on our everyday life making it quite difficult to maintain. 1. zebra config files are a nightmare. You can't drive the configuration file easily. namely : Can't edit indexs via HTTP or configuration. all is in files hardcoded on disk. ⇒ you can't list indexes you can't change indexes, you can't edit indexes, you can't say I want this index at OPAC, that in intranet. (Could be done with scraping ccl.properties, and then record.abs and bib1.att…. But what a HELL) So you cannot customize configuration defining the indexes you want easily. And ppl donot get a translation of the indexes since all the indexes are hardcoded in the ccl.properties and we donot have a translation process so that ccl attributes could be translated into different languages. 2. no real-time indexing : the use of a crontab is poor: when you add an authority while creating a biblio, you have to wait some some minutes to end your biblio (might be solved since zebra has some way to index biblios via z3950 extended services, but hard and should be tested and at the time community first tested that, a performance problem was raised on indexing.) 3. no way to access/process/delete data easily. If you have indexes in it or have some problems with your data, you have to reindex the whole stuff and indexing errors are quite difficult to detect. 4. during index process of a file, if you have a problem in your data, zebraidx just fails silently… And this is NOT secure. And you have no way to know WHICH biblio made the process crash. We had a LOT of trouble with Aix-Marseille universities that have some arabic translitterated biblios that makes zebra/icu completly crash ! We had to do some recursive script to find 14 biblios on 730 000 that makes zebra crash (even is properly stored & displayed) 5. facets are not working properly : they are on the result displayed because there are problems with diacritics & facets that can't be solved as of today. And noone can provide a solution (we spoke about that with indexdata and no clear solution was really provided. 6. zebra does not evolve anymore. There is no real community around it, it's just an opensource indexdata software. We sent many questions onlist and never got answers. We could pay for better support but the fee required is quite deterrent and benefit is still questionable. 7. icu & zebra are colleagues, not really friends : right truncation not working, fuzzy search not working and facets. 8. we use a deprecated way to define indexes for biblios (grs1) and the tool developped by indexdata to change to DOM has many flaws. we could manage and do with it. But is it worth the strive ? I think that every one agrees that we have to refactor C4::Search. Indeed, query parser is not able to manage independantly all the configuration options. And usage of usmarc as internal for biblio comes with a serious limitation of 9999 bytes, which for big biblios with many items, is not enough. BibLibre investigated in a catalogue based on solr. A University in France contracted us for that development. This University is in relation with all the community here in France and solr will certainly be adopted by all the libraries France wide. We are planning to release the code on our git early spring next year and rebase on whatever Koha version will be released at that time 3.4 or 3.6. Why ? Solr indexes with data with HTTP. It can provide fuzzy search, search on synonyms, suggestions It can provide facet search, stemming. utf8 support is embedded. Community is really impressively reactive and numerous and efficient. And documentation is very good and exhaustive. You can see the results on solr.biblibre.com and catalogue.solr.biblibre.com http://catalogue.solr.biblibre.com/cgi-bin/koha/opac-search.pl?q=jean http://solr.biblibre.com/cgi-bin/koha/admin/admin-home.pl you can log there with demo/demo lgoin/password http://solr.biblibre.com/cgi-bin/koha/solr/indexes.pl is the page where ppl can manage their indexes and links. a) Librarians can define their own indexes, and there is a plugin that fetches data from rejected authorities and from authorised_values (that could/should have been achieved with zebra but only with major work on xslt). b) C4/Search.pm count lines of code could be shrinked ten times. You can test from poc_solr branch on git://git.biblibre.com/koha_biblibre.git But you have to install solr. Any feedback/idea welcome. -- Henri-Damien LAURENT BibLibre

23 67

Meeting solr : Schedule
by LAURENT Henri-Damien 07 Dec '10

07 Dec '10

Hi, We plan to do 2 meetings around solr so that the most people can be aware of the status of our work on solr. The two meetings scheduled are : Tuesday 7th, 21PM UTC Wednesday 15th 11AM UTC Main aim is to present our work, what we did and what we are to do, and try and gather good will and try and unite. It is still early stage though we worked hard, and those meetings can also be the place where you can provide feedback and questions. Schedule is : - We will first try and state the reasons that prompted us into that rewrite. - Then we will present what is working at this stage, and the way one can setup a new install - and the bricks we chose in order to make things more flexible - What we will do (What has to be done) - What could be done - Our ideas for a better integration * use cases on search so that we could have Unit tests on search * Development of modules with ZOOM for Data::SearchEngine We hope you can be there or read the logs. Any further questions you may want to ask can be asked on list. -- Henri-Damien LAURENT

3 4

New Koha Mailing List - Koha Docs
by Nicole Engard 07 Dec '10

07 Dec '10

Hi all, Thanks to Henri-Damien at BibLibre we now have a working mailing list for sending patches to the documentation. Visit: https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-docs and sign up if you want to help out with the manual. The manual is available via the official git repo: http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary , just make sure you update the right version - there are now 3.2 and 3.4 manuals in that repo. If you would like to start a new language file, just let me know and I'll put some files in your language folder to get you started. Thanks a bunch, Nicole C. Engard Documentation Manager

1 0

Suppressing records in Koha 3.2.x
by Altaf Mahmud 06 Dec '10

06 Dec '10

Hello, Can someone please tell me how can I query to list the suppressed items in Koha database? Which database field indicates that the item is suppressed in OPAC view? Thanks. -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh.

4 8

Re: [Koha-devel] [Koha-patches] [PATCH] [Bug 5465] Makefile.PL asks for too high version of Business::ISBN
by Chris Nighswonger 02 Dec '10

02 Dec '10

CC'ing the dev list.... On Thu, Dec 2, 2010 at 11:16 AM, Liz Rea <lrea(a)nekls.org> wrote: On Thu, Dec 2, 2010 at 9:39 AM, Chris Nighswonger < cnighswonger(a)foundations.edu> wrote: > On Thu, Dec 2, 2010 at 9:48 AM, Liz Rea <lrea(a)nekls.org> wrote: > >> Backing down the version to 2.0301 to match the Lenny available package. >> > > Hmm... 2.05 is the newest version of this module in cpan. I think > Makefile.PL should always ask for what is truly the newest version rather > than being tied to a particular distribution. > > my $0.02 worth > > Kind Regards, > Chris > > I did actually think about this before I did it. :) > > I asked around if it would be better to update the documentation to take > the package out of the install script and add it to the CPAN list, or do > what I did, and the general consensus was that backing down the required > version was a better option (since the newer version doesn't add any > functionality that we actually use), so I did that. > > The reason is that a lot of people use Lenny (and or Ubuntu, which would > cause this same issue), and Squeeze/Sid aren't stable yet (even though they > work fine, I know that). Every indication I've gotten is that "we" prefer > packaged versions of things instead of pulling direct from CPAN. I chose to > eliminate the error message when installing on Lenny/Ubuntu from > Makefile.PL, and allow a required version that was lower than the current > version to help eliminate a bad user experience (An error!!! OMG! What do I > do!). > > I truly don't care which way it's done: we can remove it from the package > script and add it to the modules requiring installation through CPAN, no > problem. I'll do those patches too, if necessary. > > That said, I don't think the reasoning behind this particular patch is > unsound, based on past precedent. > I'm not familiar with what has been the rule in the past. However, it is my opinion we should establish one standard rather than attempting to work around two different ones. If we are going to take the Debian/Ubuntu repo version as the standard, we should set all modules available in those repos to the max current version available in those repos, and be sure that policy is clear in the docs. We should also develop only over those currently available versions. (I realize in this particular case there is no programmatically compelling reason to use the latest version, but that is not always the case.) FWIW, I favor Debian/Ubuntu personally, but am concerned about this from a policy standpoint. If we indeed see this as the best direction to go, I recommend we add something like this to our coding guidelines: When/Where available, Koha Perl dependencies should be sourced from the current stable Debian/Ubuntu repository. Perl dependencies not available in the repository should be sourced from CPAN. Code development should be limited to the most current version available from the proper source. Exceptions to this policy may be made by gaining consensus from the developer section of the community. or some such language... Kind Regards, Chris

6 7

About Hourly loans RFC
by Paul Poulain 02 Dec '10

02 Dec '10

Hello world, I can't see who really wrote http://wiki.koha-community.org/wiki/Hourly_Loans_RFC, if it's still planned, who will write this great RFC. Do I miss something ? Is it an abandonned_RFC from LL (don't think so, we had http://wiki.koha-community.org/wiki/Hourly_circulation_policies_RFC that was the LL one if i'm not mistaking) ? hint/light welcomed ;-) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

2 2

Meeting solr doodle tendencies closing tomorrow
by LAURENT Henri-Damien 02 Dec '10

02 Dec '10

Hi, here are the tendencies for the solr meeting : Tuesday, 7th december, 21h UTC and Wednesday, 15th December, 11h UTC I propose that we close the vote on Monday, at 21PM UTC in order to be able to have the time to send a mail for final votes. As a side note, non techy people are welcome at this meeting. Even though techy questions will be assigned. Feel free to invite. mibbit is a very handy tool to attend irc. I still have to make a real agenda for this meeting with all the questions people raised, why we did this, how we solved some issues, what drove our choices and what is the plan, and how we can work all together is still a good starting point. It will be posted on the wiki and here. Only 12 people voted. It is a good start though. I think there are many things that we could work on in groups. The search engine is one of them, Data persistance, and Plack another, Template organisation another, choosing one javascript framework (concensus seems to be in favour of jquery, but how, who when actions ?) .... if you like the idea of those meetings, please feel free to support the idea and come to those meetings and eventually organize one on the theme you favor or need. -- Henri-Damien LAURENT

5 4

ICU chains
by Ian Walls 01 Dec '10

01 Dec '10

Fellow Kohackers, There has been some talk before of using ICU chains with Zebra in order to resolve issues with diacritic search. I've looked at the patch from BibLibre ( http://git.biblibre.com/?p=koha;a=commit;h=c2465153cccb8965b0008186cdb0a94a…) and it seems pretty straightfoward, but it's nearly a year old, and I'm wondering if any work has been done since then. Does this commit resolve the issue (at least for French diacritics)? There has also been some recent posting on handling both Roman and Devangari script ( http://old.nabble.com/Re:-display-search-result-problem-p28106148.html) It references the BibLibre commit. If this methodology is working, what should we do to get it committed to Koha? I'd imagine that we'd need to generalize it to work with all languages... either by making a master set of rules, or having different xml files that can be called depending on your language choice... ideas? Cheers, -Ian -- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls(a)bywatersolutions.com Twitter: @sekjal

3 2