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

Catalogue API
by Alan Millar 17 May '02

17 May '02

I'd like to help a little in development or code clean-up. But, wow, it looks like it's going to be a full time job just keeping track of the mailing list(s), Wiki, and IRC logs... I'd like to throw in my opinion on some development directions, but I can't figure out where I should be doing it, so I guess I'll do it here :-) This is all hobby for me; I have about 1500 books in my personal collection that I want to catalog. I don't have the same issues that "real" libraries have. In that context, I really like MARC compatibility so I can snarf data from elsewhere to avoid data entry, but I don't want to eat/sleep/breath MARC records as my way of working on the data. Yes, I understand that some librarians do want that. The library patron will never want to see MARC data, so if for no other reason than that there will always need to be an abstraction of the data, such as making bibliographic data separate from individual item copy data. I think that the current three-tier structure of biblio, biblioitems, and items is actually a very good one. There are some comments on the Wiki about the Catalogue API saying that the kohadb functions would eventually go away when the Marc stuff is done. That looks like a bad move to me. I think the functions should definitely stay abstracted at the level of add/update/delete bilbio information and add/update/delete item copy information. As long as updates are done through the API, the kohadb could go away (although I'm not convinced that is a good idea, and if updates are done through the API it wouldn't need to) but the data model should not go away. I'd like to see (and want to help) Koha extend to have some smoother handling for other item types, such as music CD's or videos, including using EAN/UPC codes like how ISBN's are used for books. Would the pure MARC version handle this equally well? Also, I've read a little on the Lib of Congress discussions for XML representation of MARC data. It seems short-sighted to me to tie the database too closely to the text-only view of MARC, down to the $ subfield delimiters. I'm not at all suggesting putting XML in the Koha database; rather arguing for a higher-level abstraction that can represent the MARC data without being too file-format specific. As a non-library person, I may be all wrong here, but thanks for letting me share my thoughts. - Alan -- ---- Alan Millar --==> am12(a)bolis.com <==--

2 2

marc stuff
by paul POULAIN 16 May '02

16 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 15 May '02

15 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 15 May '02

15 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