- Koha - lists.katipo.co.nz

Re: [Koha] MySQL and foreign keys
by Joshua Brindle 17 Jan '03

17 Jan '03

This goes along with my other email about modularizing authentication. My feeling is that most of koha is sort of embedded, like auth the storage should be modularized, like this there should be a wrapper with default methods that do something a default way, one of those would be search. the mysql search would use mysql features (ie: full text search), a postgres search would do whatever they do. basically you'd have custom queries for each DBM since each method that does the querying would be DBM specific. Only the parent class would hold static variables and things that would be consistant across all the DBM's. If done this way storage is trivial, one could store everything in flat text files if they wanted!. I must emphasize that this is the *correct* way to program things like this, and if we (my university) decides to use Koha I will certainly help wherever i can. Joshua Brindle UNIX Administrator Southern Nazarene University >>> Chris Cormack 01/16/03 04:10AM >>> On Thu, Jan 16, 2003 at 11:02:43AM +0100, paul POULAIN said: > Chris Cormack a ?crit: > > >Hi There > > > >Just to throw in my 2 cents worth, i dont see using mysql fulltext > >searching > >as ruling out db independence. > >It just forces us to code more carefully, perhaps setting a value in > >/etc/koha.conf usefulltext=yes or the like. Which we can then use to > >decide > >whether to make a standard like search, or to use a fulltext index. > > > BUT : the standard like search is UNUSEABLE on a 50 000+ biblio DB, as > every search means a full parsing of the table. > If you add the same thing for the thesaurus table, which is widely used > in marc cataloguing, and some other place where full text indexing will > be usefull... > Hi Again paul :) Well maybe not 50,000 .. but 500,000+ ... its working ok for HLT's 78709 biblios. But I take your point, and agree wholeheartedly the current search code badly needs a rewrite and lots of optimisation. And im sure HLT wouldnt say no to any speed increase :-) I think what i was trying to say (bear in mind its getting late here, and my mind is probably muddled :-)) was that we should be able to provide the option for other people to use a database of their choice. Without restricting those who want to from using mysql fulltext indexing. On the topic of fulltext searching we had a discussion about it on irc today. I cant currently get to the irc logs but when i can, ill mark the discussion and post the url to the devel list. Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris(a)katipo.co.nz www.katipo.co.nz _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

4 4

Where is the Supplier Information?
by Ingrid Lacis 17 Jan '03

17 Jan '03

Hi - I'm testing Koha and I can't seem to locate the supplier information as illustrated in your documentation. (The vendor details, ordering information, shopping basket) Thank you, Ingrid Lacis

2 1

Re: some thoughts about cataloguing and acquisitions [important]
by Stephen Hedges 16 Jan '03

16 Jan '03

Hi, Paul, and thanks for opening an interesting topic - I think that a strong acquisition component would be a very valuable asset for Koha. In fact, I think acquisitions are much more important than cataloging. That means that I support your idea of separating the two, so it would be easier (to my mind) to focus development effort on acquisitions. If they are not separated, then I think cataloging should at least be handled as a sub-task of acquisitions. My thoughts are based on my experience with library users and librarians. We have found that library users appreciate the ability to make purchase suggestions and see what the library has on order, even place reservations on items before they arrive at the library. In other words, a good acquisitions system allows users to see not only what the library has, but what the library WILL have, and also gives them the power to suggest and reserve things the library has not ordered. That means the acquisition system needs to deal in records that are nearly complete, so people can search for items by title, author, ISBN, subject, etc. Cataloguing, in that case, merely adds the "labeling" to the item once it arrives, i.e. barcodes, spine labels, etc. The item has already been cataloged in all other respects as soon as it is ordered. As for librarians, I had a conversation with the tech guy from Worthington Public Library who suggested that they might be willing to put money toward a really good Koha acquisitions system, one that would allow the librarian to automatically search for an item and compare prices from several different vendors and download any MARC records available from vendors with a minimum of effort on the part of the librarian. He had other thoughts, as well, because he had been wrestling with searching for a good acquisitions system for some time, but I unfortunately can't remember them now. Both of these experiences lead me to believe that any ILS that wants to be competitive in the future should pay close attention to its acquisitions component. I think both library users and librarians are going to demand much more functionality than what is currently available in most ILS acquisitions systems. Stephen H. > I want here share some ideas for the 2.0 version > of koha, around > cataloguing and acquisition. > > Most ILS, in France at least, separate > cataloguing and acquisition. > * *cataloguing* is often done through a CDROM > (from the BNF for example) > : the librarian download from the cd the biblio > in MARC format, which is > included in it's ILS. The cataloguing refers only > to BIBLIO notice, not > items and how they arrive in the library. > * *acquisition* referers to how "books" arrive in > the library (and > includes items) > > In koha, at the moment, there is no distinction > between those 2 topics : > look at koha main page, there is only a > "acquisition" picture, which > includes cataloguing and acquisition in fact. > I want to begin de debate to see if it's a good > idea to distinct > acquisition and cataloguing in 2.0. > It would mean : > * in mainpage => 2 links for cataloguing and > acquisition > * acquisition => works almost like the normal > acquisition system of the > old version : search for a supplier, enter a > little part of the biblio... > * cataloguing => > - if marc is selected : works like the > acqui.simple in 1.3.3 (see > demo.koha-fr.org) > - if marc is not selected : works like the 2nd > part of the normal > acquisition in 1.2 : enter the biblio details. > this supposes a new parameter in the > systempreferences table. > > One other idea : it would enable a "suggestion" > feature in the opac : > readers could suggest books to add, which could > be stored in the > "acquisition" part of koha, in a "to validate" > status. > > From a developper point of vue, this means : > * duplicating biblio table to acqui_biblio table > * split normal acquisition in 2 parts > * change normal acquisition to write acqui_biblio > table and not biblio > * create some screens to link the acquisition > part and the cataloguing one. > some work, but not too much i think (if someone > wants to fund it, send > me a mail :-) ). > > Of course, if you create a book in the > acquisition part, all what you > typed would be auto-copied when entering the > cataloguing part :-) > So there should not be too much more work for the > librarian/cataloguer > (but a few, anyway : this would add screens, so, > more clics) > > -- > Paul POULAIN > Consultant indépendant en logiciels libres > responsable francophone de koha (SIGB libre > http://www.koha-fr.org) > >

1 0

RE: [Koha] MySQL and foreign keys
by Williams, Olwen - SAL 16 Jan '03

16 Jan '03

I'm not about to argue one database over another. I've worked a lot in databases that don't enforce integrity, and you need to include the integrity in your code. This is sometimes easier said than done. We began using Postgres at the very start of Koha, but found problems making some queries run efficiently. MySQL ran them so we changed. I don't know to what extent the problem were in my lack of experience and how much was the fault of Postgres, and how much the two database have changed in the meantime. -----Original Message----- From: Larry Currie [mailto:lcurrie@CalAcademy.Org] Sent: Thursday, January 16, 2003 1:38 PM To: koha(a)lists.katipo.co.nz Subject: [Koha] MySQL and foreign keys Last night I attended a PerlMongers group meeting here in Oakland, CA and one of the presenters at the meeting asserted that MySQL could not claim to be a completely relational database because it doesn't let you define foreign keys. As a result, he feels that MySQL fails the ACID test (atomicity, consistency, referential integrity, and durability), and he advised people to avoid using it in Perl applications and instead use Postgres or some other relational database with more stability. He cited an example where you might have a one-to-one relationship between primary key values in two tables and if you deleted a value from one of the tables, MySQL would leave that value in the other table as dangling data without warning you to take care of it and as a result really mess up your database. Can anyone on the Koha list comment on this assertion and what the consequences might be for Koha? ____________________________________________________________________ CAUTION - This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify Safe Air Ltd immediately. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Safe Air. _____________________________________________________________________ For more information on the Safe Air Group, visit us online at http://www.safeair.co.nz/ _____________________________________________________________________

4 3

Problems modifying a new record
by Jim Thomas 16 Jan '03

16 Jan '03

Hi all, We have recently installed Koha at our school, and today our librarian ran into some trouble when she tried to modify a new entry. This server is not available on the internet except via ssh (text mode). I poked around the database using mysql after she reported this problem: ============================================================================== I used the marc lookup and imported the file for Charlie Horse/Mrs. White's Secret Sock. I modified the data before saving. It set up the biblio for the book, plus my item number 5658. Then I later realized that I wanted to add one more subject to the subject listing. I looked up Charlie Horse in the catalog. I clicked on it which gave me the Biblio. I clicked on modify. Even though the biblio showed subject lines, the subject lines were missing on the modify screen! I input the one it wanted to add and clicked the query(save) button. Normally it flips me to the new modified biblio, but this time it only brought up a blank biblio. I again looked up Charlie Horse in the catalog. This time before trying to add the new subject, I realized that when I added it to the catalog in the first place I caused an accidental mispelling to the title. I tried to fix that only, but with no more success than when I had tried to add the subject line. Finally I decided that I would delete the entire thing and start again. I had to first delete my item number 5658. Then I deleted the biblio. At that point both the book title and item number no longer showed up when I searched the catalog. So I assumed everything had been erased out and went to start all over again on the book. But the computer would act like the biblio was already there and prompt me for an item number. It would act like it was taking the item number -- no error messages or warnings that the number was already in use. But then when I would look up Charlie Horse, the title was there but it refused to say that there was an item in the library. ============================================================================== I don't really know my way around in MySQL - just enough to be dangerous. And I really don't know how the db is laid our in Koha. Here's what I found/did. I found that the original biblionumber for the "Charlie Horse" book was 934, and the new one had a biblionumber of 940. biblioitems and bibliosubject both still had entries for biblionumber 934, which I deleted. The items table still had an entry for biblionumber="934", but no entry for biblionumber="940". So I did an update items set biblionumber = "940" where barcode="5658"; Which seemed to partially fix the problem. After I did this, she tried to do a dummy checkout of the book, but it couldn't find it. Can anyone advise me at this point? Are there other tables I need to modify? Should I refrain from manipulating the db with mysql (yes)? -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas(a)bittware.com http://www.bittware.com (703) 779-7770 I thought I was wrong once, but I was mistaken.

4 8

MySQL and foreign keys
by Larry Currie 16 Jan '03

16 Jan '03

Last night I attended a PerlMongers group meeting here in Oakland, CA and one of the presenters at the meeting asserted that MySQL could not claim to be a completely relational database because it doesn't let you define foreign keys. As a result, he feels that MySQL fails the ACID test (atomicity, consistency, referential integrity, and durability), and he advised people to avoid using it in Perl applications and instead use Postgres or some other relational database with more stability. He cited an example where you might have a one-to-one relationship between primary key values in two tables and if you deleted a value from one of the tables, MySQL would leave that value in the other table as dangling data without warning you to take care of it and as a result really mess up your database. Can anyone on the Koha list comment on this assertion and what the consequences might be for Koha? Larry Currie -- Lawrence W. Currie User Services Librarian California Academy of Sciences Golden Gate Park San Francisco, CA 94118 lcurrie(a)calacademy.org (415) 750-7108 (415) 750-7106 fax http://www.calacademy.org/research/library/

4 7

some thoughts about cataloguing and acquisitions [important]
by paul POULAIN 16 Jan '03

16 Jan '03

I want here share some ideas for the 2.0 version of koha, around cataloguing and acquisition. Most ILS, in France at least, separate cataloguing and acquisition. * *cataloguing* is often done through a CDROM (from the BNF for example) : the librarian download from the cd the biblio in MARC format, which is included in it's ILS. The cataloguing refers only to BIBLIO notice, not items and how they arrive in the library. * *acquisition* referers to how "books" arrive in the library (and includes items) In koha, at the moment, there is no distinction between those 2 topics : look at koha main page, there is only a "acquisition" picture, which includes cataloguing and acquisition in fact. I want to begin de debate to see if it's a good idea to distinct acquisition and cataloguing in 2.0. It would mean : * in mainpage => 2 links for cataloguing and acquisition * acquisition => works almost like the normal acquisition system of the old version : search for a supplier, enter a little part of the biblio... * cataloguing => - if marc is selected : works like the acqui.simple in 1.3.3 (see demo.koha-fr.org) - if marc is not selected : works like the 2nd part of the normal acquisition in 1.2 : enter the biblio details. this supposes a new parameter in the systempreferences table. One other idea : it would enable a "suggestion" feature in the opac : readers could suggest books to add, which could be stored in the "acquisition" part of koha, in a "to validate" status. From a developper point of vue, this means : * duplicating biblio table to acqui_biblio table * split normal acquisition in 2 parts * change normal acquisition to write acqui_biblio table and not biblio * create some screens to link the acquisition part and the cataloguing one. some work, but not too much i think (if someone wants to fund it, send me a mail :-) ). Of course, if you create a book in the acquisition part, all what you typed would be auto-copied when entering the cataloguing part :-) So there should not be too much more work for the librarian/cataloguer (but a few, anyway : this would add screens, so, more clics) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

Re: [Koha-devel] MySQL and foreign keys (fwd)
by Pat Eyler 16 Jan '03

16 Jan '03

might as well put this here too ... just to satisfy the folks who wondered about Larry's question. -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org ---------- Forwarded message ---------- Date: Wed, 15 Jan 2003 19:27:32 -0500 (EST) From: Pat Eyler <pate(a)eylerfamily.org> To: Larry Currie <lcurrie(a)CalAcademy.Org> Cc: koha-devel(a)lists.sourceforge.net Subject: Re: [Koha-devel] MySQL and foreign keys well, there are a couple of ways to respond. First, MySQL does have foreign keys: http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html (There area also some specific dis-advantages to using foreign key enforcement listed near the bottom of the above document.) Secondly, the question of whether of not MySQL is ACID capable has little to do with its suitiblity for our purposes. MySQL is frequently used by serious websites to do serious business (NASA among them), I think that properly used, MySQL is a completely valid choice for building an ILS. -pate Pat Eyler Kaitiaki/manager migrant Linux sys admin the Koha project ruby, shell, and perl geek http://www.koha.org http://pate.eylerfamily.org On Wed, 15 Jan 2003, Larry Currie wrote: > Last night I attended a PerlMongers group meeting here in Oakland, CA > and one of the presenters at the meeting asserted that MySQL could not > claim to be a completely relational database because it doesn't let you > define foreign keys. As a result, he feels that MySQL fails the ACID > test (atomicity, consistency, referential integrity, and durability), > and he advised people to avoid using it in Perl applications and instead > use Postgres or some other relational database with more stability. He > cited an example where you might have a one-to-one relationship between > primary key values in two tables and if you deleted a value from one of > the tables, MySQL would leave that value in the other table as dangling > data without warning you to take care of it and as a result really mess > up your database. > > Can anyone on the Koha list comment on this assertion and what the > consequences might be for Koha? > > Larry Currie > > -- > Lawrence W. Currie > User Services Librarian > California Academy of Sciences > Golden Gate Park > San Francisco, CA 94118 > lcurrie(a)calacademy.org > (415) 750-7108 > (415) 750-7106 fax > http://www.calacademy.org/research/library/ > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: A Thawte Code Signing Certificate > is essential in establishing user confidence by providing assurance of > authenticity and code integrity. Download our Free Code Signing guide: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en > _______________________________________________ > Koha-devel mailing list > Koha-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/koha-devel > ------------------------------------------------------- This SF.NET email is sponsored by: A Thawte Code Signing Certificate is essential in establishing user confidence by providing assurance of authenticity and code integrity. Download our Free Code Signing guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en _______________________________________________ Koha-devel mailing list Koha-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel

1 0

Introduction
by Bernadette Cassidy 15 Jan '03

15 Jan '03

Kia ora everyone, I've recently joined the list and this is my brief introduction. I am the Library & Learning Coordinator at the Allan Bean Centre for Research and Learning in Rehabilitation at Burwood Hospital, Christchurch, New Zealand. The library is primarily for patients, their families and carers as well as staff and aims to provide good quality information resources for people recovering from serious injury or illness. At present we do not have a library management system or catalogue for our users. I'm looking very closely at Koha as a possible solution but we will need to look at some of the specifications more closely. One of which is having a Linux machine set up - and the minimum specification needed for setup etc. I would be interested to hear from others in a similar situation for advice and suggestions etc. Kind regards, Bernadette Cassidy Allan Bean Centre Coordinator Burwood Academy of Independent Living Burwood Hospital Christchurch Email: bernadettec(a)burwood.org.nz Tel: 03 383 9484 Fax: 03 383 9582

1 0

Re: [Koha] Re: MARC support
by Joshua Brindle 15 Jan '03

15 Jan '03

What is the timeline for the authentication stuff? I've gone through some of the authentication stuff and it seems deeply embedded (ie: not modular) to do this right the authentication should be completely abstracted from the app and allow a simple drop in authentication replacement. If this were the case i'd happilly write the ldap stuff. Are there plans to modularize all this stuff? Thanks.... Joshua Brindle UNIX Administrator Southern Nazarene University >>> paul POULAIN <paul.poulain(a)free.fr> 01/15/03 03:27AM >>> Joshua Brindle a écrit: Wow!, that would be the perfect thing to be in the installation docs :\ In fact, it's the perfect thing to test during the installation process. I'll fix this for 1.9.0 seriously, i didn't even think to check CPAN for the module, i assumed it was part of Koha. Thanks a lot... Also, do you guys think that koha can handle my library? 90000 books, maybe a dozen librarians and a couple thousand patrons? I'd have to make it authenticate to LDAP rather that mysql but that should be trivial... Thanks again Without any problems (if you don't plan to install it on a Pentium 100 server :-) ) About LDAP : others also ask for this. the management team plans to : * release 2.0 with authentification as it is, through mysql tables. * add differents auth methods in the 2.1 or 2.2 version -- Paul POULAINConsultant indépendant en logiciels libresresponsable francophone de koha (SIGB libre http://www.koha-fr.org)

2 1