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

opac-search.pl
by Toni Rosa 09 Nov '10

09 Nov '10

Hello, We are using Koha 3.0.5 I noticed that the opac advanced search in it (opac-search.pl) when running in a nozebra installation doesn't honor "publication period" intervals (e.g entering the 1800-1900 interval the search doesn't work). I followed the code to the "C4/Search.pm" file, method "NZanalyse" and it seems that it actually doesn't even try to build the sql query taking the intervals into account. Did anyone find the same behavior? (I'd guess everybody should, as it seems a bug/omission to me!) Thanks, Toni

4 6

General meeting on IRC: Wednesday, 10 November 2010 at 19:00 UTC+0
by Magnus Enger 09 Nov '10

09 Nov '10

Hi All Our next IRC meeting is on Wednesday, 10 November 2010 at 19:00 UTC+0 on the #koha irc channel on irc.katipo.co.nz. The agenda is here: http://wiki.koha-community.org/wiki/General_IRC_Meeting,_10_November_2010 Currently the agenda looks like this: * Update on Roadmap to 3.2 * Update on Roadmap to 3.0 * Update on Roadmap to 3.4 1. BibLibre branches submitted to QA (roadmap & what's still expected from BibLibre. feedback from librarians) * Community building : 1. RFCs agreement workflow (discussion about the workflow for RFCs to be accepted/validated) 2. git management (branches) 3. jqueryui adoption instead of YUI 4. proposal to form a Technical Committee * Follow-up on actions from General IRC Meeting, 6 October 2010. * Agree times of next meetings. Please feel free to edit the agenda to add any issues you would like to talk about, and feel free to attend the meeting using your favourite irc client. Best regards, Magnus

2 1

Mails when patch pushed to git
by Paul Poulain 09 Nov '10

09 Nov '10

Hello, In the mail we recieved when RM/RMaint pushes a patch to git.koha-community.org I'd be happy to have the details of the patch. For instance, the mail contains: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "main Koha release repository". > OK (even if it could be shorter maybe) > The branch, master has been updated > via e5bdc1e9ab9465c618968eb32f2adbfeee56c445 (commit) > via 4e11a5ade37485a2822d7ce9682fbd84e4d6637b (commit) > via 20dce153b1f785a758d6924103e51a6cef173fd3 (commit) > via 653259e6216efa9359c6c8022de42a342e4a14d1 (commit) > from 5145eb59b786bd2010eb324197034dd210504543 (commit) > What can I do with the previous information? seems cryptic to me unless someone explains (note I know it's a git patchid, but as is, in the mail, I don't see how it is useful) > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > Is the previous paragraph needed? > - Log ----------------------------------------------------------------- > commit e5bdc1e9ab9465c618968eb32f2adbfeee56c445 > Merge: 5145eb59b786bd2010eb324197034dd210504543 4e11a5ade37485a2822d7ce9682fbd84e4d6637b > Author: Chris Cormack <chrisc(a)catalyst.net.nz> > Date: Wed Nov 3 16:52:21 2010 +1300 > > Merge remote branch 'kc/new/bug_5308' into kcmaster > > ----------------------------------------------------------------------- > > Summary of changes: > installer/data/mysql/kohastructure.sql | 11 ++++++++--- > installer/data/mysql/updatedatabase.pl | 27 +++++++++++++++++++++++++++ > 2 files changed, 35 insertions(+), 3 deletions(-) > > Well, I would be VERY interested by the detailled content of the changes ! For at least 2 reasons : - if I have a patch waiting, it's unclear if that's what I've submitted or not. + as chris (3.4RM) pushed through a patch, we can't know who is the original author of the patch. - I could do a post-push if needed. Is it possible to improve the hook? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

5 4

DBIx::Class vs current Koha's DBI performance
by Dobrica Pavlinusic 08 Nov '10

08 Nov '10

I just figured out today that kohacon10 is in progress, and one of topics seems to be DBIx::Class migration. Let me start by saying that I'm all for it, but probably not for same resons as everybody else. I was trying to profile koha search page. On first run under Devel::NYTProf it showed 2220 invocations of DBI::st::execute. That's more than 2000 calls which wait for database to return answer. This might explain extremly high usage of mysql query cache which I'm seeing in production: http://mjesec.ffzg.hr/munin/koha/koha-mysql_queries.html So, I decided to experiment a bit. and few patches later I was able to reduce number of queries issued on each page load down to 876 If you are interested in what I changed, my code is at: http://git.rot13.org/?p=koha.git;a=shortlog;h=refs/heads/nytprof-cache It's basically using either global hash to cache values per request of simple memoize around function. Which brings me back to DBIx::Class. If we can cache values using dbic, this will be huge WIN for Koha performance as opposed to loss :-) I never used dbic in that contex, but google seems to think it's possible, and I'm willing to take a try at it. -- Dobrica Pavlinusic 2share!2flame dpavlin(a)rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin

9 16

Webcam Barcode reader
by Charl 05 Nov '10

05 Nov '10

Did anyone try the ZBar open source webcam barcode reader? Is it practical to use in a library environment?

3 2

RDA and Koha - where we are and HOW do we get ready
by dschust1＠tx.rr.com 05 Nov '10

05 Nov '10

The final report for RDA will be out in the spring and RDA records are already being created and loaded into OCLC that Koha libraries are trying to use. Library of Congress will most likely adopt and start cataloging next year in RDA format - my personal suspicion. FRBR has been out for 10 years and WE(librarians) have not made much of a concerted effort to make that work I believe because we(librarians) didn’t know what RDA was going to do. This might be a project that we all(librarians and programmers) need to figure out what needs to be done - create a committee and spec out the work and we all pay to have the work done. What I hear from vendors is Until LIBRARIANS can tell the vendor what the LIBRARIANS/USERS WANT/NEED vendors don't know where to begin. There is a LOT of coding that needs to be done not only for bibliographic items but for Authorities to work right not to mention the RDA changes to Authorities. I've seen lots of discussion around Authority work and I would hate to see a library do authority programming NOT based on RDA specs at this point. Joy M. Banks Catalog Librarian came up with these starting points for Koha and RDA - The system needs to be able to uniformly display both the GMDs that are in current AACR2 records and the new 3xx fields that RDA would implement to replace GMDs (this is a big one since I don’t know about anyone else, but we have no intention of going back to update all of our AACR2 records to RDA) - The system needs to take into account a new FRBR model that will both serve the needs of patrons who wish to find every manifestation of a particular work and also those who wish to see specific manifestations - The system needs to be able to perform global updating for authorities so that changes made to authority records will be automatically applied to the bibliographic records to which they are attached - Any development with authorities and display also needs to take into account what will soon be a proliferation of $e’s in 1xx and 7xx fields (this one is fuzzier for me… I’m not quite sure if I’ve captured this change). These subfields should only affect the bibliographic records, not the authorized forms of the headings. She also suggested this: Mac Elrod has developed a kind of cheat sheet (http://slc.bc.ca/cheats/aacr22rda.htm) that highlights some of the major RDA changes. It’s from September, but at least it’s something that we can consider. So where do we start and begin working on this? I believe Ian touched the tip of the iceberg during KohaCon10 in this regard. I'd love to start the dialog and see where it NEEDS to go. David Schuster Plano ISD

2 1

Oracle nerfs MySQL, calls it MySQL classic, and charges $2, 000+ for features like InnoDB
by Kyle Hall 04 Nov '10

04 Nov '10

http://www.mysql.com/products/ <http://www.mysql.com/products/>I imagine this is going to impact Koha quite a bit, as Koha has been using InnoDB for quite a while now. Switch to Postgres? Kyle http://www.kylehall.info Mill Run Technology Solutions ( http://millruntech.com ) Crawford County Federated Library System ( http://www.ccfls.org ) Meadville Public Library ( http://www.meadvillelibrary.org )

4 9

bugzilla question
by Marcel de Rooy 04 Nov '10

04 Nov '10

Hi, Couldn't find this on the wiki. Should I leave a bug on resolved/fixed, resolved/invalid etc. or should they always go to closed in the end? Just some number: resolved+fixed=2636 bugs. Closed/fixed= only 78. Regards, Marcel

2 1

itemBarcodeInputFilter or Client side JS?
by Koustubha Kale 03 Nov '10

03 Nov '10

Hi All, We are implementing Koha at a college. They have a existing software for library. They have barcoded all their collection of about 150000 books with this software. The peculiar thing about the software and the barcode it generates is this : The barcode related data stored in the database of the software backend ( MS SQL) is the item's accession number & item type. The actual barcode is not stored anywhere. The printed barcodes are like this B011364, B011436, AR011346, AR011436,AR018100,AR018103,AR018104,AR018105. ( Note the duplicate accession numbers) The first alphabets correspond to the itemtype code stored in a table. The remaining numbers are the accession number stored in a table without the leading zeros. This causes a problem while migrating this data to Koha due to the missing leading zeros and arbitrary length of the string and the fact that accession numbers are same for different item types. While generating a barcode for a new item the software takes the itemtype and the accession number and prints out a barcode label in the required format. When the barcode is read back in the softwares circulation module by a barcode reader, a asp script on the server separates the item type and the accession number, strips the leading zeros from the numeric part and does a search on the database by means of a join on the two tables. As the college has stuck these barcode labels on all items, we have to figure out how to emulate this functionality in Koha. (Post migration we will generate & print barcodes from Koha; so we dont have to emulate this logic in the barcode generation for Koha). I was thinking we could store the barcode in Koha as itemtype-accession_number ( without the leading zeros e.g. AR-18100) retrieved from the old softwares database and when reading it in circulation in Koha we convert the barcode from for example AR018100 to AR-18100. I see two options to acchieve this.. options : 1) Create another filter for itemBarcodeInputFilter and modify the sub barcodedecode in C4/Circulation.pm 2) write a client side javascript to do it. I would like to know is 1) What is the better way to acchive this? 2) Is there way for us to avoid a patch to Koha which will probably be useless to anybody not migrating from this particular software. By using opacuserjs perhaps.. Regards, Koustubha Kale Anant Corporation Contact Details : Address : 103, Armaan Residency, R. W Sawant Road, Nr. Golden Dyes Naka, Thane (w), Maharashtra, India, Pin : 400601. TeleFax : +91-22-21720108, +91-22-21720109 Mobile : +919820715876 Website : http://www.anantcorp.com Blog : http://www.anantcorp.com/blog/?author=2

4 6

Classification Sources
by Cybermon 03 Nov '10

03 Nov '10

Dear Koha team, Can I use two classification sources for cataloging of Koha. For example, both of DDC and LCC. Sorry I could not find the BBK Classification of Russian in Koha. Please someone help about it. Gana

2 1