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

marc stuff
by paul POULAIN 17 May '02

17 May '02

I've commited my marc stuff in the main branch. I've done this because when i asked for a marc branch i thought the main branch was the stable one. As Chris explains me it was the dev one, i think we don't need a marc branch. Why ? Because I want the marc-compliance for september-02, so i will have a hard work on it, and it should be in the next release (1.4 ?) Hope kiwis have had a good night, and americans will have to. See you tomorrow -- Paul

2 3

Re: [Koha-devel] Question on proper/preferred DBI usage?
by Alan Millar 16 May '02

16 May '02

I definitely do not want to get into a flame war on this, so if it turns that direction, I'll drop the subject. On Thu, May 16, 2002 at 03:42:30PM +1200, Gynn Lomax wrote: > The reason it has been done this way is simple: > I like to be able to see what values I am assign to where. > With the values embedded into the query it means I can directly see what > they match up with, e.g.: > > $query = "Insert into biblioitem set > biblionumber = $biblioitem->{'biblionumber'}, > itemtype = $biblioitem->{'itemtype'}"; I haven't looked at enough of the code, but I haven't see much of that in the code. I see things like: $sth=$dbh->prepare("insert into biblioitems (biblioitemnumber, biblionum ber, volume, number, itemtype, isbn, issn, dewey, subclass, publicationyear, pub lishercode, volumedate, volumeddesc, illus, pages, notes, size, place, lccn, mar c) values ($biblioitemnumber, $biblionumber, $q_volume, $q_number, $q_itemtype, $q_isbn, $q_issn, $q_dewey, $q_subclass, $q_publicationyear, $q_publishercode, $ q_volumedate, $q_volumeddesc, $q_illus, $q_pages, $q_notes, $q_size, $q_place, $ q_lccn, $q_marc)"); and I'm definitely having a hard time matching up which variable goes with which column name. > With the bind values method you get: > $query = "Insert into biblioitem set > biblionumber = ?, > itemtype = ?"; > > followed by later: > $sth->execute($biblioitem->{'biblionumber'}, $biblioitem->{'itemtype'}); > > While for this simple example it is easy to see which value matches up, for > more complicated queries, and those that have a lot of values it can start > to get mor confusing. With this method, as well as the example above (straight from marcimport.pl), in my opinion the main problem is formatting. Compare, for example, the following actual code: ------------------------------------------------------------- my $q_isbn=$dbh->quote($isbn); my $q_issn=$dbh->quote($issn); my $q_lccn=$dbh->quote($lccn); my $q_volume=$dbh->quote($input->param('volume')); my $q_number=$dbh->quote($input->param('number')); my $q_itemtype=$dbh->quote($input->param('itemtype')); my $q_dewey=$dbh->quote($input->param('dewey')); my $q_subclass=$dbh->quote($input->param('subclass')); my $q_publicationyear=$dbh->quote($input->param('publicationyear')); my $q_publishercode=$dbh->quote($input->param('publishercode')); my $q_volumedate=$dbh->quote($input->param('volumedate')); my $q_volumeddesc=$dbh->quote($input->param('volumeddesc')); my $q_illus=$dbh->quote($input->param('illustrator')); my $q_pages=$dbh->quote($input->param('pages')); my $q_notes=$dbh->quote($input->param('note')); my $q_size=$dbh->quote($input->param('size')); my $q_place=$dbh->quote($input->param('place')); my $q_marc=$dbh->quote($input->param('marc')); $sth=$dbh->prepare("insert into biblioitems (biblioitemnumber, biblionum ber, volume, number, itemtype, isbn, issn, dewey, subclass, publicationyear, pub lishercode, volumedate, volumeddesc, illus, pages, notes, size, place, lccn, mar c) values ($biblioitemnumber, $biblionumber, $q_volume, $q_number, $q_itemtype, $q_isbn, $q_issn, $q_dewey, $q_subclass, $q_publicationyear, $q_publishercode, $ q_volumedate, $q_volumeddesc, $q_illus, $q_pages, $q_notes, $q_size, $q_place, $ q_lccn, $q_marc)"); ------------------------------------------------------------- with this functional equivalent: ------------------------------------------------------------- $sth=$dbh->prepare("insert into biblioitems (biblioitemnumber, biblionumber, volume, number, itemtype, isbn, issn, dewey, subclass, publicationyear, publishercode, volumedate, volumeddesc, illus, pages, notes, size, place, lccn, marc) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) "); $sth=$dbh->execute( $biblioitemnumber, $biblionumber, $input->param{'volume'}, $input->param{'number'}, $input->param{'itemtype'},$input->param{'isbn'},$input->param{'issn'}, $input->param{'dewey'}, $input->param{'subclass'}, $input->param{'publicationyear'}, $input->param{'publishercode'}, $input->param{'volumedate'}, $input->param{'volumeddesc'}, $input->param{'illustrator'}, $input->param{'pages'}, $input->param{'note'}, $input->param{'size'}, $input->param{'place'}, $input->param{'lccn'}, $input->param{'marc) ); ------------------------------------------------------------- I'm sure it is just a matter of what each person is accustomed to, but I can match up parameters easier in the second example than I can in the original. > For the very few queries I have run across that are executed more than once, > the values being put into them are an unknown list (in terms of length), > e.g. > > $query = "Insert into deleteditems values (" > foreach my $value (@results) { > $value = $dbh->quote($value); > $query .= "$value,"; > } # foreach > > and I'm unsure if the bind values method can handle this, so avoided it. This code snippet looks like it is inserting an "unknown list" of column values into a table, on the assumption that the unknown list just happens to match up with the exact correct order of columns in the table. This is different than the original issue which is in the context of inserting multiple rows, not columns. I'm definitely going to be stepping into hot water here, and so I must apologize in advance for that. But as to the columns, it seems to me to be unsafe coding practice to insert values into a table without column names, because somebody somewhere is going to do some db modification, whether through custom changes or version upgrades, and some column will missing or out of order and it will break. Hashes perhaps are a good solution for this type of thing. In any case, the bound parameter method works just fine for this: $query = "Insert into deleteditems values (" foreach my $dummy (@results) { $query .= "?,"; } # foreach $query=~s/,$/\)/; $sth->execute(@results); And there is probably a shorter way to do the correct number of question marks via a count of @results. > The other advantage of the method I have used is that you can print out the > entire query before it is executed - so you can examine it for bugs. Whereas > with the bind value method you never get to see the query in it's entirety. OK, with the quoted method you only have to print one thing, while with the bound method you have to print more. That's true. I sure don't want to start a flame war, and if it sounds like I am, please just ignore me and I'll drop it. Thanks for the education on another point of view. - Alan -- ---- Alan Millar --==> am12(a)bolis.com <==--

5 4

spanish work on koha
by Pat Eyler 16 May '02

16 May '02

Nick, How far do we want to go in getting koha in front of hispanic developers and users? The recent moves in Mexico by Hispalinux may prove another good avenue for us to approach this potential audience. -pate

1 0

PLEASE, help me...
by paul POULAIN 16 May '02

16 May '02

Yesterday I asked for the structure of the websites table. I still have no answers. Today, I will ask for the "uploadedmarc" table structure (in acqui.simple). PLEASE, when you update you local mysql-DB, don't forget cvs ignore it, so update database.mysql immediatly, so I will be able to do the changes also... I've searched "uploadedmarc" table everywhere and could'nt find it ;-((( Thanks. This day was a boring day : searching for biblio-adding problem without any result, and trying to work on marc stuff with no more success :-\\\\\\\ -- Paul

4 8

DBI digest
by Douglas Bagnall 16 May '02

16 May '02

Alan wrote: > foreach my $dummy (@results) { > $query .= "?,"; > } # foreach > And there is probably a shorter way to do the correct number > of question marks via a count of @results. That would be the x operator. '?,' x 4 eq '?,?,?,?,' cheers, Douglas

1 0

coding practices
by paul POULAIN 16 May '02

16 May '02

I will try to build a page with "coding practices" for koha on the wiki. It will contain Alan proposal about perl/mysql proposals (use of ? where it causes no read-havoc. For example, in a prepare("select x,y,z from table where param=?"). In this case, it's undoubtfully more readable. I also want to ask about an eternal question : Do we use tab or space for indenting our programs ? I prefer tabs. For instance, soft is indented sometimes with spaces, sometimes with tabs, which makes them not easily readables. what's your opinion ? -- Paul

2 1

Question on proper/preferred DBI usage?
by Alan Millar 15 May '02

15 May '02

Hi- I hope this doesn't sound like criticism of the efforts so far; I think Koha is excellent work. However, I'm wondering about the DBI usage in the code. It appears that everything I've read on DBI says not to put variables into the SQL statement but to use placeholder parameters instead. For example, right now everything looks something like this: my $q_value=$dbh->quote($value); my $sth=$dbh->prepare("select my_field from my_table where my_criteria=$q_value"); $sth->execute; Whereas what I've read on the subject says it should be done like: my $sth=$dbh->prepare("select my_field from my_table where my_criteria=?"); $sth->execute($value); This doesn't require double the variables for all the quoting, and in a loop the prepare only has to be done once. I'm especially confused about things I see in the code like: $biblioitem->{'volume'} = $dbh->quote($biblioitem->{'volume'}); I think I'd be confused in keeping track of which things you have or haven't quoted already. I'd like to contribute to the project, and I'm happy to clean up things like this as I come across them. I'm wondering if there is a particular reason it's being done the way it is, or did it "just happen" this way? Thanks! - Alan -- ---- Alan Millar --==> am12(a)bolis.com <==--

2 2

adding biblio
by paul POULAIN 15 May '02

15 May '02

I've just commited 2 small corrections in newbiblio and addorder scripts. But my question is still here ! When you're on a basket and click on a biblio link, you're asking the system to do something strange... I explain : you call "newbiblio.pl", which mean you want to ADD a biblio/biblioitem. See, for example, barcode calculation in newbiblio.pl. Chris told me it was supposed to EDIT the biblio/biblioitem. I dig 3 hours in this code, and still does not understand what happends, where it's wrong, and how to correct. What i'm sure, is that it has a strange behaviour. Could someone (from katipo maybe) have a *deep* look and explain me or correct the problem ? -- Paul

2 1

public irc logs
by Tonnesen Steve 15 May '02

15 May '02

Anybody have any feelings on making irc logs publically available? I've got a logger running on the channel now and a web page for viewing the logs. If nobody objects to public logs, I'll post a link on the wiki. If somebody objects, I won't post the link, or I'll make the log site password protected. Steve.

2 1

Marc Branch
by Chris Cormack 14 May '02

14 May '02

Hi all As requested by Paul i have created a branch called rel-1-4-marc that ppl can use to work on the marc version. Id also like to see if we can organise some kind of group session to knock out any bugs in the rel-1-2 branch. And see if we can progress towards a 1.2.0 stable release. Perhaps we need that Release manager to crack the whip :) Chris -- Chris Cormack chris(a)katipo.co.nz Programmer 025 500 579 Katipo Communications www.katipo.co.nz

2 1