This is a bit technical and arcane, but I want to mention it because I’ve seen a lot of recent patches still using the old style of code calling $sth->finish() explicitly.  I know a lot of the codebase still does this internally, but for Koha such usage is almost always wrong.

If this were just my personal contention, I would couch this in terms of an RFC to deprecate the usage.  But we don’t get a choice here: DBI is telling us “don’t do it”.

Please refer to the DBI perldoc:

When all the data has been fetched from a SELECT statement, the driver should automatically call finish for you. So you should not normally need to call it explicitly except when you know that you’ve not fetched all the data from a statement handle. The most common example is when you only want to fetch one row, but in that case the selectrow_* methods are usually better anyway. Adding calls to finish after each fetch loop is a common mistake, don’t do it, it can mask genuine problems like uncaught fetch errors.

That last sentence is the most concrete and important (hence my bolding).  Moral of the story: don’t do it.  Or if you think you have to, at least comment why, like:

$sth->finish();  # FIXME: leaving data unfetched, should rework query

Henri-Damien Laurent, Release Maintainer for Koha 3.0, has announced the release of Koha 3.0.2, the second maintenance release of Koha in the 3.0.x series. The release tar file can be downloaded from http://download.koha.org/koha-3.00.02.tar.gz.

From Henri’s announcement:

We are very happy to announce Koha 3.0.2 Stable has been released on
http://download.koha.org/
Its name is koha-3.00.02.tar.gz You can download file and signatures

You can check the integrity of the package; either by verifying the provided
GPG signature (.sig) or by comparing the MD5 checksum:
c3fee4abbb29c88f97a5f7db5fe9eebf koha-3.00.02.tar.gz

I have also tagged this in Git as “version 3.00.02 final”
v3.00.02-final

…

This release is bugfix only release, and does not include new
features which would require some database changes.
It does add some databases changes though but only to FIX bugs.

The next release scheduled in July will include features which are now
in master but not ported yet to stable because of database change
required. That is to say mainly many content enhancement were not
integrated Librarything, Syndetics, Baker&Taylor, Babeltheque, and
BranchTransferLimits.
But we are willing to make them into the next release which will come
out as soon as possible in July.

Update: BibLibre’s announcement (in French).

Recently, I’ve been asked to add tagging to the guided reports section. I used this as an opportunity to implement a mixin that’s similar in spirit to acts_as_taggable for Ruby’s ActiveRecord ORM.

I called this class, “C4::Taggable”, and it will inject tagging-related methods to any class that uses it. Normally, it’s bad form to use Exporter in OO code, but that mainly applies to when you’re defining a class. However, when you’re defining a mixin, I believe the use of Exporter is justified, because it’s one of the easiest ways to inject methods into a namespace.

To illustrate this technique, here is an outline of how C4::Taggable is implemented. (For brevity’s sake, the method bodies were omitted.)

C4::Taggable

  package C4::Taggable;
  use strict;
  use warnings;
  use base 'Exporter';
  use C4::Context;
  our @EXPORT_OK   = qw( add_tag remove_tag tags search_by_tags                );
  our %EXPORT_TAGS =   ( mixin => [qw(add_tag remove_tag tags search_by_tags)] );

  sub add_tag        { }
  sub remove_tag     { }
  sub tags           { }
  sub search_by_tags { }

  1;

Notice how C4::Taggable exports tagging-related methods.

Next, C4::Report is outlined. Note that by using C4::Taggable, C4::Report became taggable by virtue of having tagging-related methods for C4::Taggable being mixed into it.

C4::Report

  package C4::Report;
  use strict;
  use warnings;
  use C4::Context;
  use C4::Taggable ':mixin';

  sub new            { }
  sub id             { }
  sub borrowernumber { }
  sub date_created   { }
  sub last_modified  { }
  sub savedsql       { }
  sub last_run       { }
  sub report_name    { }
  sub type           { }
  sub notes          { }
  sub update         { }

  sub table          { }

  1;

Isn’t that simple? Now any time you want to add tagging to a class, you just use C4::Taggable.

What’s the catch?

The catch is that C4::Taggable will have expectations about the host class and the database schema. The host class has to provide a few methods so that C4::Taggable can introspect enough to generate the right SQL. There will also be a table you have to create that has a predefined structure and naming pattern. I won’t go into any more detail here, but suffice it to say that for C4::Taggable to work, certain conventions have to be followed.

To me, it’s a small price to pay, because it makes it ridiculously easy to add tagging to other classes should that ever be necessary or desired.

David Schuster has announced a meeting of KUDOS (Koha Users and Developers of Open Source) at the annual meeting of the American Library Association in Chicago.

Date: Sunday, 7/12/2009
Time: 1:30 pm - 3:00 pm>
Location: Hyatt Regency Chicago (not the Hyatt that’s close to the
convention center)
Room: Grand Suite 3

Henri-Damien Laurent, Release Maintainer for Koha 3.0.x, has published a new Git tree with a candidate for Koha 3.0.2. From his original announcement:

I am glad to announce that work for stable version 3.0.2 is well advanced.
You can test it on koha-maintenance project
see http://git.koha.org/cgi-bin/gitweb.cgi?p=koha-maintenance.git;a=summary
for the code.

How can I test it ?
if you have a dev version :
git remote add maintenance git://git.koha.org/pub/scm/koha-maintenance.git
git fetch maintenance
git branch –track testing_3.0.2 remotes/maintenance/master
git checkout testing_3.0.2

Any bugs should be reported to Henri-Damien directly — since the changes have not been pushed yet to the 3.0.x branch in the main public repository, any issues are technically not bugs against that maintenance branch. Henri-Damien and I discussed whether or not to create a new product or component in the bugs database for his maintenance tree, and for now have agreed not to do that. Once initial testing of his koha-maintenance tree has been completed, Henri-Damien will be merging it into the main repository’s 3.0.x branch and any remaining 3.0.2 issues can be filed in Bugzilla. Of course, if this doesn’t work out, say if if Henri-Damien gets absolutely deluged with emails about the 3.0.2 candidate, we can revisit this decision.

Many thanks to Henri-Damien for working so hard on 3.0.x.

I just sent a call for the next general IRC meeting of the Koha project, which will take place on 3 June 2009 at 10:00 UTC+0. Here’s a link to one time zone converter. We’re currently seeking a major coffee company to sponsor caffeine for North America and New Zealand. The initial agenda for the meeting is on the Koha wiki; to propose new items, please update the wiki page or post to the Koha mailing list. At the moment there are three standing agenda items:

1. Update on 3.2
2. Update on 3.0.x
3. Follow-up on actions from the 6 May 2009 IRC meeting.

I look forward to seeing everybody there.

The first general IRC meeting of the Koha project in a long time took place today. For those who couldn’t make it, a log of the discussion is available. The agenda for the meeting is on the wiki.

Some highlights from the meeting:

1. Koha 3.2 will be frozen for new features at the end of August. After two months for testing and translation, general release will be at the end of October. I will release a pre-alpha version of Koha 3.2, which will include the acquisitions work by BibLibre, during the month of June, and I plan on another intermediate pre-alpha release between June and August.
2. Henri-Damien Laurent plans two releases in the 3.0.x maintenance branch, 3.0.2 in June and 3.0.3 shortly thereafter to reconcile differences between the 3.2 tip and the 3.0.x branch.
3. There was a long discussion of the Koha bugs database. At KohaCon, users and potential users of discussed ways to keep track of potential developments to Koha and arrange sponsorships to fund the enhancements. We’ll be using the Koha bugs database to do this, and this will mean some changes to it (adding a field to record sponsorship status) as well as promoting the use of it.
4. I will start a weekly blog for news about the progress of 3.2.
5. We’ll start sending a monthly FAQ to the Koha mailing list and improve the welcome message to new subscribers. I will draftask Nicole Engard to help out with composing it, but if you have ideas for what this message should include, I’ve started a page on the wiki.
6. Nearly two and a half hours into the meeting, we talked a bit about KohaCon 2009, which was very successful. Thanks to David Schuster and the Plano Independent School District for hosting it, and thanks to the members of the KohaCon planning committee for doing a superlative job.

I would like to thank everybody who participated. Special thanks to MJ Ray for taking care of many wiki updates during the meeting. I’ll be calling another IRC meeting to occur in early June.

This morning one of the Koha Librarians created a page on the Koha Wiki for everyone to share their Custom Reports/SQL statements. This from Owen at Athens County:

Koha users have begun building a library of useful SQL statements for use in building Koha reports. It’s on the Koha Wiki. You can add your own or put in a request for a report you’d like to know how to do. If you’d like to contribute you can either register on the site or use OpenID to log in. If you’ve never edited a wiki before, be sure to check out the Formatting Syntax article before you jump in.

Technorati Tags: koha

Anyone who has ever watched the MySQL query log while koha serves requests knows that koha makes A LOT of repetitive SQL queries for every request.  Most of these requests are for individual values in the systempreferences table.  There is also another large batch of queries for data from the language_descriptions table.  The queries are not that heavy by themselves, but there are way too many of them happening per request, and it’s for the same data every time.

In an attempt to minimize the number of repetitive queries, I tried to make koha use memcached.

(more…)

Please mark your calendars for KohaCon 2009. From David Schuster’s announcement today:

KohaCon 2009 will be held in Plano, TX April 16 and 17.

This is a FREE conference. There is no registration fee, but we are
requesting that all attendees pre-register. Details (travel, hotels, agenda draft, etc) can
be found at:

Koha WIKI: http://wiki.koha.org/doku.php?id=kohacon2009

There is a “Tentative Schedule” - it will change as more people sign up
probably for programs. Travel information along with Hotel accomodation
information. Lunch and dinners will be on your own. Feel free to contact
any of the three people listed on the Wiki at the top or email me directly.

After the conference, there will be a three-day Koha developers meeting in Plano on April 18 through 20. All who develop for Koha, want to develop for Koha, or are interested in Koha development are welcome to attend.