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

RE: [Koha-devel] Re: [Koha] latest on PostgreSQL
by Anthony W. Youngman 07 Oct '02

07 Oct '02

One (to me extremely annoying) nitpick. Using SQL does NOT make it db-independent. It merely makes it rdb-independent ... I had an offline discussion with Pat about MaVerick, which is not a relational database but is probably more suited to Koha than SQL. Unfortunately, the hassle of switching (plus the fact MaVerick is immature) probably means an attempt at changing isn't worth it. btw, Andrew, please can you get rid of that damn flag ... :-) Cheers, Wol (if you're interested, www.maverick-dbms.org) -----Original Message----- From: Andrew Arensburger [mailto:arensb+koha-devel@ooblick.com] Sent: 07 October 2002 13:49 To: Ervin Peters Cc: Richard Davis; koha(a)lists.katipo.co.nz; koha-devel(a)lists.sourceforge.net Subject: Re: [Koha-devel] Re: [Koha] latest on PostgreSQL On Mon, Oct 07, 2002 at 10:48:39AM +0200, Ervin Peters wrote: > But i think we should better discuss either to get it db- independent by > using only Ansi SQL or to specify the dbs in koha.conf, like 'dbs = > [mysql|pgsql|oracle|sap|ansiSQL]' The current version in CVS already allows you to do this: use the (undocumented) "db_scheme" configuration option in /etc/koha.conf: db_scheme = Pg This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system. Telephone numbers for ECA International offices are: Sydney +61 (0)2 9911 7799, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333.

2 1

Re: [Koha] latest on PostgreSQL
by Ervin Peters 07 Oct '02

07 Oct '02

Hallo ! I'm not really involved in Koha developing yet, but I downloaded Koha 1.2.2 in August and got it run on postgres to about 90%. I've done this to get familiar with Perl, dbs + www and so on... There are many things to do to get the whole System work on postgres, or better: work Database independent. The basic SQL Database Script contains MySQL specific SQL, but can be easily converted to pgsql by mysql2pgsql. The updatedb and the web scripts are more problematic, since they embed many mysql specific. I went through that script, convert on the fly the sql terms an typed it in pgsql. You could say, I updated the db by hand. The next problems are the 'replace into' statments found in many scripts, they must be changed into if 'select [pkey] from ...' then 'update ...' else 'insert into ...' construction like it is done in some module functions. If I would find the time, I'd like to specify it more detailled, later on. But i think we should better discuss either to get it db- independent by using only Ansi SQL or to specify the dbs in koha.conf, like 'dbs = [mysql|pgsql|oracle|sap|ansiSQL]' Then any code can contain 'optimizations' for dbs by check the configuration: if dbs==mysql then 'replace into..' else if 'select ...from...' then 'update ...' else 'insert...' Another possibility would be to move all dbs code in one modul and change this modul by selecting the dbs... ervin Weimar, Germany --On Montag, 7. Oktober 2002 16:04 +1300 Richard Davis <RichardD(a)pcanz.org.nz> wrote: > I read in the archives of June/July that some work was being done of > making koha work with postgres. What progress has been made? > > > > Richard Davis > Communications Advisor and Webmaster > Presbyterian Church of Aotearoa New Zealand > PO Box 9049, Wellington, Aotearoa New Zealand > Direct: +64 4 381 8285 Mobile: 027 404 8656 > Phone: +64 4 801 6000 Fax: +64 4 801 6001 > http://www.presbyterian.org.nz/ > _______________________________________________ > Koha mailing list > Koha(a)lists.katipo.co.nz > http://lists.katipo.co.nz/mailman/listinfo/koha -- Ervin Peters 99423 Weimar

4 4

search.pl from intranet
by paul POULAIN 07 Oct '02

07 Oct '02

Hi finlay, I'm working on catalogue search to add a link on the search page to see full-MARC biblio. On the version i've (cvs from main branch), when i search i see a list of biblios showing the results : Results with dewey <http://koha.dev/cgi-bin/koha/search.pl?template=cmsdsearchresults.tmpl&star…>| Results with biblionumber <http://koha.dev/cgi-bin/koha/search.pl?template=searchresults.tmpl&startfro…> ------------------------------------------------------------------------ Title Author Item Count Biblionumber Prokofiev's Peter and the wolf Morris, Johnny 1 6712 Popcorn at the palace McCully, Emily Arnold 1 28689 The Pandora option Rathbone, Julian 1 28801 Blossom like the rose Lofts, Norah 1 29648 Prague and the best of the Czech Republic Mastrini, John 1 31922 The Everest Hotel Sealy, Allan 1 19067 Neither here nor there Bryson, Bill 2 27587 Bishop Selwyn in New Zealand, 1841-68 1 4863 The fighting Temeraire 1 17050 The searching spirit Adamson, Joy 1 4628 Previous Records <http://koha.dev/cgi-bin/koha/search.pl?template=&startfrom=0> Next Records <http://koha.dev/cgi-bin/koha/search.pl?template=&startfrom=10> Results 1 through 10 of 14612 records. ------------------------------------------------------------------------------------------------------------------------------------------ But if I clic on a link (next, previous...), i get nothing usefull (an empty liste usually). And where should I clic to see the detail of a title ? I think either i'm doing something wrong, or there is a problem... what do you think ? Note : i've modified a few things not working because of hard-coded url in templates. -- Paul

1 0

about "Replaced several prepare()/execute()/finish() sequences with do()."
by paul POULAIN 07 Oct '02

07 Oct '02

Just 1 remark about few of your CVS commits : we have decided to use prepare("update xx where yy=?"); execute($yy_value); If there are prepare("update xx where yy=$yy_value") execute(); then it's because nobody moved this query to ? syntax. Thus, - $query = "insert into biblio set - biblionumber = $bibnum, - title = $biblio->{'title'}, - author = $biblio->{'author'}, - copyrightdate = $biblio->{'copyright'}, - serial = $series, - seriestitle = $biblio->{'seriestitle'}, - notes = $biblio->{'notes'}, - abstract = $biblio->{'abstract'}"; ! $sth = $dbh->prepare($query); ! $sth->execute; should be $query = "insert into biblio set biblionumber = ? title = ? author = ? copyrightdate = ? serial = ? seriestitle = ? notes = ? abstract = ?"; $sth = $dbh->prepare($query); $sth->execute($bibnum,$biblio->{'title'},...); and not ! $dbh->do(<<EOT); ! INSERT INTO biblio ! SET biblionumber = $bibnum, ! title = $biblio->{'title'}, ! author = $biblio->{'author'}, ! copyrightdate = $biblio->{'copyright'}, ! serial = $series, ! seriestitle = $biblio->{'seriestitle'}, ! notes = $biblio->{'notes'}, ! abstract = $biblio->{'abstract'} ! EOT -- Paul

1 0

we've got a winner :-) => IMPORTANT
by paul POULAIN 07 Oct '02

07 Oct '02

I hope everybody has been VERY CAREFUL on C4::context.pm that Andrew posted yesterday... It's really a GREAT SCRIPT : * well documented * nice and clean perl * very useful. * extendable as we want and need. I think everybody should follow andrew paths... For the coming scripts, i STRONGLY recommend to use C4::context.pm and forget anything else... About parameters : ------------------------- I think we're on a dangerous way... some parameters are in /etc/koha.conf, some are in systempreferences table. I think, and chris too, that we should use koha.conf ONLY for DB parameters, and systempreferences for everything else. Example : it's bad, i think, to have theme in systempref and theme-path in koha.conf. Does anyone have an objection ? -- Paul

3 5

Search UI
by Andrew Arensburger 06 Oct '02

06 Oct '02

There's been some talk here about improving the searching code. It seems to me that a lot can be done by improving the user interface. Currently, the internal and OPAC search pages have three types of searches, but this isn't obvious. There's the search by bar code, which returns information about a specific item. There's the "fuzzy" search by author, title, etc. which searches for a combination of criteria. There's the subject search, which searches for known subjects, not books. On the internal search page, the barcode search is visually distinct from the other searches, so it's intuitively obvious that they're two different types of searches and should return different results. On the OPAC page, however, all of the fields are grouped together, giving the impression that it's just one tyep of search. If you see Author: _________________ Title: _________________ [Search] you naturally assume that you can fill in "Asimov" and "Astronomy", and get books with "Asimov" as the author AND "astronomy" in the title. Therefore, you conclude, if you see Author: _________________ Title: _________________ Subject: _________________ [Search] you can fill in "Asimov" as the author and "astronomy" as the subject, and get all the books written by Asimov on the subject of astronomy. This isn't what the page does: it ignores the author entirely, and displays a list of subjects that have the word "astronomy" in them. Likewise, it doesn't make sense to combine the barcode with anything else, such as an author. The barcode uniquely identifies a book, so either the author will match and return the same result as the barcode alone, or it won't and the search will return nothing. Finally, there's only one "OK Start Search" button on the page, which reinforces the impression that everything is part of one big search. This is true, actually: there's only one <form> block on the search page, and the code in C4/Search.pm jumps through all sorts of hoops to see which fields were specified and which ones weren't, and try to guess from that what kind of search the user wants to perform. IMHO it'd be better to start by changing the page layout: Keywords: ________________ Author: ________________ Title: ________________ (*) Normal ( ) Exact Series: ________________ (*) Normal ( ) Exact Illustrator: _____________ Subject: ________________ Item type: [Choose an item type] [Search] -------- Subject: ________________ [Search] -------- Barcode: ________________ [Search] (And maybe drop the Dewey search. I don't know.) For the first search, all of the terms would be combined: the search would return all books that match all of the criteria. The second search would return a list of subjects, the way it's currently done. The third search would find a specific book, as you'd expect. This layout seems more intuitive to me. (The in-store search thingy at Borders has a different interface: a pull-down selection box allows you to choose whether you want to search by author, title, or keyword. But I think the above is better, since it allows you to narrow the search by providing more terms.) The underlying HTML would then contain three <form> blocks. Each one could then include a field like <input type="hidden" name="type" value="by-barcode"> which would take the guesswork out of the code that actually performs the search and make it easier to Do The Right Thing. Thoughts? Opinions? Dissent? -- Andrew Arensburger This message *does* represent the arensb(a)ooblick.com views of ooblick.com A running program is the moment of truth. All else is either prophecy or nostalgia.

3 3

Circular dependencies
by Andrew Arensburger 06 Oct '02

06 Oct '02

I ran 'perl -wc' on a few of the C4 modules, and found that there are a number of circular dependencies, i.e., cases where two modules have "use" statements pointing at each other, or where Module1 uses Module2, which uses Module3, which uses Module1. Thanks to the magic of 'find | grep | tsort', I'm appending a list of these cycles at the end of this message. But 'perl -wc Module.pm' will also tell you if there's a cycle, by complaining that all of the functions in "Module.pm" are redefined. At first, I thought this meant that the first file in the loop would get read twice, but this doesn't appear to be the case. However, I think this does indicate spaghetti code and/or lack of modularity. -- Andrew Arensburger This message *does* represent the arensb(a)ooblick.com views of ooblick.com Do you want to make people's heads explode? Sure! We all do! C4/InterfaceCDK.pm C4/Circulation/Renewals.pm C4/Circulation/Issues.pm C4/Circulation/Main.pm C4/Reserves.pm C4/Interface/ReserveentCDK.pm C4/InterfaceCDK.pm C4/Accounts.pm C4/Interface/AccountsCDK.pm C4/InterfaceCDK.pm C4/Circulation/Renewals.pm C4/Interface/RenewalsCDK.pm C4/Accounts.pm C4/InterfaceCDK.pm C4/Circulation/Renewals.pm C4/Circulation/Issues.pm C4/Circulation/Main.pm C4/Reserves.pm C4/Accounts.pm C4/InterfaceCDK.pm C4/Circulation/Renewals.pm C4/Circulation/Issues.pm C4/Circulation/Main.pm C4/Circulation/Returns.pm C4/Search.pm C4/Reserves2.pm C4/Accounts.pm C4/InterfaceCDK.pm C4/Circulation/Renewals.pm C4/Circulation/Main.pm C4/Circulation/Issues.pm C4/Circulation/Borrower.pm C4/Circulation/Main.pm C4/Accounts.pm C4/InterfaceCDK.pm

2 3

Missing deleted* tables?
by Andrew Arensburger 06 Oct '02

06 Oct '02

If I understand correctly, the purpose of the deleted<foo> tables in the database is to provide a backup of any rows that may have been deleted from the <foo> table. That is, when an item is deleted, it isn't actually deleted, it just gets moved from the items table to the deleteditems table. That way, if something is deleted accidentally, it can (in principle) be restored. Is this correct so far? If so, it seems to me that there should be more deleted* tables, such as deletedbibliosubject and deletedbibliosubtitle, since the biblio table has "links" to various other tables, containing data that also should be saved in a backup table. Or am I on the wrong track here? -- Andrew Arensburger This message *does* represent the arensb(a)ooblick.com views of ooblick.com I play an important role as a bad example.

1 0

C4::Context
by Andrew Arensburger 05 Oct '02

05 Oct '02

Just to keep people informed (those who don't get CVS logs, at least): I've updated Koha to use C4::Context->dbh instead of &C4Connect throughout (RTFM C4::Context(3) for more details, or 'pod2text C4/Context.pm'). In a nutshell, $dbh = C4::Context->dbh returns a database handle, creating one if necessary. It is not necessary or even desirable to call $dbh->disconnect, since this handle is persistent, and gets closed when the script terminates. -- Andrew Arensburger This message *does* represent the arensb(a)ooblick.com views of ooblick.com This land is your land. This land is my land. So stay on your land.

1 0

Re: [Koha-devel] we've got a winner :-) => IMPORTANT
by Chris Cormack 04 Oct '02

04 Oct '02

On Fri, Oct 04, 2002 at 02:29:01PM +1000, Roger Buck said: > > Roger Buck wrote: > > > requires that we run six virtual hosts and a complicated file structure > > > with lots of duplication. This also means that I have spent a lot of > > > time evauating various options for file structure and configuration. > > > Chris Cormack wrote: > > Hmm I think you could get around this quite easily by setting an ENV > > variable in apache for your virtual hosts with the location of koha.conf in > > it. Then making Output.pm fetch it from the environment variable. > > We could set this up quite easily for you if you liked? > > > > Also with the use of Alias and ScriptAlias commands you could remove all > > duplication, see below for an example. > > Hmmm I think I know exactly what you're talking about... and I think I > understand how it works... but I still think there is a better option... > that works just as well for large installations as for small. > > > > > Especially with the move to templates, so there will be no more static html > > files > > OK... maybe I have misunderstood the current situation... or maybe the > templates will overcome some/all of this stuff: > > 1. Under current setup, I see no clear distinction between opac and > intranet file space - for example, I might be using public opac but > public opac is calling templates + some images and includes stored in > intranet file space? This "blurring" of the lines between Opac and > Intranet will become problematic - especially where security is > concerned... but maybe for knowing "what goes where" in general? > Right, and this is why we are moving them apart. Opac stuff lives in an opac area. Intranet stuff lives in another. > > 2. By the principle of least surprise, I would expect to be able to > install and run both opac and intranet web services without requiring > virtual hosts for either - A user should be able to integrate both > services seamlessly into an existing web server - all on a single port > at a single hostname.... as well as allowing for virtual hosts if > preferred. I don't think this is currently possible "out of the box". If > not, then why not? I think it can be done with a small amount of effort, the effort will smaller as the distinction between the opac and intranet becomes bigger. > > 3. The answer to #2 above may be that opac and intranet cgi scripts and > web pages require same virtual path in webspace even though they are > stored in physically separate locations, for example: > > On OPAC virtual host: > ScriptAlias /cgi-bin/koha/ /usr/local/www/koha/cgi-bin/opac/ > ------------^^^^^^^^^^^^^-----------------------------^^^^^^ > > On INTRANET virtual host: > ScriptAlias /cgi-bin/koha/ /usr/local/www/koha/cgi-bin/koha/ > ------------^^^^^^^^^^^^^-----------------------------^^^^^^ > > This is the only reason I can see that a separate virtual host is > required? Could be lots of reasons for a separate virtual host. In fact you may actual separate hosts. One reason is the sites live on different machines. Or on different ip numbers ... only one of which is externally routable. IE your intranet is actually an intranet. > > If true, then why is it better to have multiple virtual hosts - compared > with separate physical paths in config file. I don't see any security > benefits in using virtual servers for the above case? > > Am I on the wrong track here? :) > I think perhaps we are talking past each other :-) I want virtual hosts and separate paths for the files. At least between the opac and the intranet. If you have 5 opacs though, you shouldnt need five copies of the cgi-bin and templates. You will need 5 databases and 5 koha.conf files but only one set of the cgi's. So to try and summarise I want the opac and intranet systems to be standalone. Capable of being installed on separate machines, or on the same machine using separate hosts/ipnumbers/port numbers, or on the same machine using the same host and port. IE I want it all :-) Chris

2 2