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

query optimization
by paul POULAIN 14 May '02

14 May '02

Many queries are build with : (title like '$key[0]%' or title like '% $key[0]%') I was wondering why : * title like '$key%' is index optimizable * title like '% $key%' is NOT index optimizable. optimizable OR not optimizable === NOT optimizable. So the resulting query is not optimizable. So, what's the interest of such a string, as "title like '%'.$key.'%'" has the same result ? -- Paul

2 2

is it a bug ? or I need some explanations...
by paul POULAIN 14 May '02

14 May '02

Hi, I'm working on koha-cvs. I've found a technical bug which hides maybe a functionnal problem. Let me explain : Acquisition. I search a supplier (one I've added recently). It shows a basket (HLT-1064, created 3 days ago), which I click on. I go to basket.pl. This basket contains 1 line, for an item called "madeleine samedi2", qty=1, $est=7 (ok, that's the item I had added. It was a new biblio) When I click on the title, i go to newbiblio.pl. "92536 - Order Detail". Item barcode/Actual cost/Invoice number is empty ( ?? I filled them at the first order). When I validate, I get an error => acquisition.pm due to addorder.pl error : at line 61, $bibitemnum=newbiblioitem($bibnum,$itemtype,$isbn); should be : $bibitemnum= &newbiblioitem({ biblionumber => $bibnum, itemtype => $itemtype?$itemtype:"", isben => $isbn?$isbn:"" }); (thanks to use strict here, it must be a long time ago bug...) Now, i get no technical bug, but... a new "biblioitems" record is created. I think it's a bug, but can someone explain me what's supposed to do the title link in basket.pl. Thanks -- Paul

2 2

Re: [Koha] schema question
by Pat Eyler 13 May '02

13 May '02

Stuart, I'm forwarding your message to the development list where it stands a better chance of being answered. If you're interested in implementing functionality such as this, you may want to subscribe to the development list. thanks, -pate On Mon, 13 May 2002, <s.yeates(a)cs.waikato.ac.nz> wrote: > > Hello > > I've got a couple of quick questions about the Koha database schema. I think I've worked it out, but just want to double check. I'm working from the CVS version and data. > > I'm interested in implementing a collaborative recommendation feature which allowed users to see which books other people who borrowed the current book had also borrowed. Both Amazon and Barnes and Noble use a similar feature. > > In English the query I want is "Which books have been lent to the most people who have also borrowed the current book?" With the restriction that the books I recommend must be available for lending from the current library (it's pointless recommending a book that's not there) and must have more than N borrowers in common with the current book (to protect the privacy of borrowers, N is set to 5 or 10). > > Logically what I want to do is a join across biblio--> items--> issues--> borrowernumber--> issues--> items--> biblio with SELECT, a COUNT and a SORT. This, of course, gives huge intermediate tables, so I'd have to do several SELECTs as I go. > > I may also need to factor in a component of "how much has book A been borrowed by borrowers of book B compared to all other borrowers" to prevent very popular items (think Harry Potter) being recommended for every possible book. This effect would be similar to tf-idf ranking from classical information retrieval. > > My questions are: > (1) How do I tell whether a book is 'available'? I think I need to check the items table and make sure that stack, notforloan, itemlost and wthdrawn are all zero does this sounds right?. > (2) I don't understand the distinction between items and biblioitems > (3) How to I differentiate between children's and adult's books, between fiction and non-fiction? > (4) Would collaborative recommendation be useful in a small library catalog? > (5) Would the small incursion of user privacy be acceptable in a small public library? > > thanks for your help > stuart > > > > > -- stuart yeates <s.yeates(a)cs.waikato.ac.nz> aka `loam' > "To err is human--but it feels divine." -- Mae West > X-no-archive:yes > > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha >

1 0

templating
by Tonnesen Steve 13 May '02

13 May '02

After a bit of playing with HTML::Template I have the following proposal Templates stored in includes directory under templates subfolder, each module (ie search, circ, catalog, etc.) has another subfolder, then another subfolder for each template, and then subfolders for each version of that template. Includes Templates Search Opac Search default.tmpl polish.tmpl french.tmpl local.tmpl Librarian Search default.tmpl polish.tmpl french.tmpl local.tmpl Opac Results default.tmpl Librarian Results default.tmpl We could then have a preference order for choosing templates, ie: local french default If a local template is available, it is used first, then the french template, falling back on the default template if no other is available. I don't know if this is too complicated, or too simple. What do we do if we have three different "default" opac results templates? What about a per-user preference for different templates? Maybe language should be dealt with completely separately... Just airing some thoughts... Steve.

5 4

Have fun...
by Nicholas Rosasco 11 May '02

11 May '02

No objections having been recorded .... The log of the meeting (at least until it wound down and I left) is at http://etome.net/Koha/minutes/meeting-Koha.txt if anyone wants to read something like 3/4 hours of IRC :) -- Simon said he'd get a who-does-what email out soon based on the meeting (thank heaven, as at least I was running principally on caffeine!). Nick

1 0

Double checking m'self
by Nicholas Rosasco 11 May '02

11 May '02

I've doubled checked my email, and I think I've updated (maybe not prettily, but updated) the Wiki in spots based on recent requests and the best version of the working list for the current version. Please tell me if you want anything else in there in the short term, as I may go back an clean things up/de-cruftify. Nick

1 0

hola (fwd)
by Pat Eyler 11 May '02

11 May '02

Thought I'd pass this along to the list. I'm trying to recruit some help in developing and internationalizing koha ... this was my first shot at it. thoughts, comments, questions? -pate ---------- Forwarded message ---------- Date: Thu, 9 May 2002 11:30:34 -0400 (EDT) From: Pat Eyler <pate(a)eylerfamily.org> To: webmasters(a)www.gnu.org.pe Subject: hola hola, yo habla un poco espanol, lo siento. I hope english will work. I'm working on a free software library automation project (for traditional book/media collections) called koha (Maori for 'gift')[1]. It uses perl and mysql, and will run on a variety of free unix-like systems. Currently koha works very well for smaller libraries, and is installed at a number of libraries around the world. Our goal is to turn it into a system capable of handling large libraries, even to the point of supporting National Libraries. Given Peru's recent entrance into the limelight of the Free Software world, it would seem that there is a opportunity for co-operation. Do you know of a Peruvian organization that we could work with us to: a) help localize koha for spanish speakers b) ensure the functionality that peruvian libraries (and the peruvian governmant) need is present in koha c) help build local (Peruvian) interest in and support for koha

1 0

cvs and branching
by Pat Eyler 10 May '02

10 May '02

Here's a quick picture of how we might use CVS branches to manage our upcoming development. An explanation follows. +--MARC-+ / \ / \ -main line--+-----+-----+-------------+-+--------------+-> development \ \ / \ / \ \ / +-rel_1_4-++---> 1.4 branch \ \ / / \ +-rel_1_2-+-+---------------+------> 1.2 branch \ / \ / +---NT----+ (This picture is a gross over-simplification.) The main line is where all normal development should happen (e.g., seperation of presentation and logic and addition of http::template). Sometimes it makes sense to create a branch. This could be to stabilize a release (e.g., re_1_2 and rel_1_4) or to integrate big changes that have happened outside the tree (e.g., MARC or NT). Branches represent temporary copies of the tree, and can be operated on (cvs add, remove, commit, checkout, update, etc) without affecting the main line. Any time we create a branch, we should plan on merging (or backporting) changes back to the main line (and perhaps to other branches as well). In the example above, we already have a rel_1_2 branch. We should create an NT and a MARC branch to hold the changes for these two development efforts. As the NT tree is solidified, we can backport it into the rel_1_2 tree and from there into the main line. Once the code has been backported, we can close this branch down. As the MARC tree solidifies, we can merge it directly back into the main line preparatory to creating the rel_1_4 branch. Again, once backported, this branch can be closed. The rel_1_2 tree should never be closed down. It will represent the ongoing work on the 1.2 stable releases. We will want to merge changes from this branch into the main line on a regular basis. Once the rel_1_4 branch is created, we can backport rel_1_2 changes into that branch as desired. After the rel_1_4 branch has been created, we will want to merge stabilization changes back into the main line from it on a regular basis. For hints on the technical bits involved in using CVS and branches, please look at http://cvsbook.red-bean.com/cvsbook.html (or, even better, buy a copy of the book).

2 4

koha development leadership
by Pat Eyler 10 May '02

10 May '02

--------------------------------------------------------------------------- NOTE: The following should be considered beta quality documentation. It represents my understanding of the rough consensus that came out of an irc meeting. Please feel free to point out mistakes, to clarify points, or suggest improvements. --------------------------------------------------------------------------- During our inaugural irc meeting last night, we talked about providing more of a leadership structure for koha to add some consistency, motivation, and vision to koha development. We talked about a couple of options, ranging from continued anarchy ("there's no leadership like no leadership") to an elected steering committee ("if a camel is a horse designed by committee ..."). In the end we settled on a happy medium ("The art of compromise is giving everyone some of what they want so that, in the end, no one is happy.") The purpose of this email is to explain the basic structure that we settled on as well as the roles and responsibilities of each position. We decided that we (the people on the development list) should elect a 'benevolent dictator' to serve us until he/she decides to pass along the baton to someone else (or looses the mandate of the development list). This person would nominate several key assistants to oversee specific areas of the koha project. This 'cabinet' should look something like this: Benevolent Dictator Release Leader Marketing Leader Recruiter Standards Liason Each of these positions is described below: Benevolent Dictator: This person is responsible for setting the overall tone of koha development. They will determine which Major features belong in a given release, which outside organizations we should focus on building relationships with, etc. Our dictator should be our visionary and strategic thinker. Release Leader: This person is chosen to oversee the development of a specific release. There may be more than one release leader concurrently (e.g., a 1.2 release leader and a 1.4 release leader), the one overseeing the tail end of development on an earlier release while the other is ramping up development on the next release. This person should be; making tactical decisions about merging or removing code, resolving conflicts, and managing a release schedule by encouraging (harassing?) developers. Marketing Leader: This person should be targeting specific organizations to approach about koha. They are not the sales arm of katipo or any other koha support/development company, instead they should be trying to increase awareness (and acceptance) of koha. Examples may be coordinating a presence at ALA regional meetings, collecting koha success stories for distribution on the devel list (and web site), and the like. Recruiter: This persons role is to find solid developers and designers to bring into the koha development and support effort. This should include international recruitment (esp. in markets determined to be important by the Marketing Leader and Benevolent Dictator). It may also include helping/mentoring likely candidates from the koha users list. Standards Liason: This person should help coordinate our standards compliance efforts. They will be tasked with gathering standards documentation and writing (or finding people to write) developer oriented documentation about the standards documentation. (An if you think that last sentence was evil, you should go read some standards documents.)

1 0

Log
by Nicholas Rosasco 10 May '02

10 May '02

I'll be posting the meeting log (if you want a look at it) after I get some sleep, unless someone has an objection. Nick

1 0