IRC log for #koha, 2007-02-16

All times shown according to UTC.

Time S Nick Message
19:03 cht greetings kohateers!
19:03 cht chris - r u there?
19:05 cht i've been working on that problem i have where default (i.e. '*") issuing rules trump specific issuing rules
19:05 cht i am beginning to suspect that i have discovered another small difference with mysql 5
19:06 cht for those of you who do not know, i am running koha 2.2.6 and mysql 5.0 on debian sarge
19:07 cht around line 628 in C4/Circulation/, there is a check to see if $result is defined
19:08 chris k
19:08 cht the expectation being that zero rows in the db yields an undefine $result...
19:08 cht however, even though the query returns zero rows, perl is finding that $result is defined
19:09 chris interesting
19:09 cht is it possible that with mysql 5 and koha's DBI code, result sets with zero rows are defined?
19:09 chris could be
19:10 chris koha doesnt use its on DBI code
19:10 chris it uses
19:10 cht **OR** - i updated to the very latest DBI/DBD perl modules - that could explain it too
19:10 chris yeah
19:10 cht there was a new release for one of them last week
19:10 chris if you change that line to
19:11 chris if (defined($result) && $result->{'itemtype'}) {
19:11 chris then it oughta work for both
19:11 cht actually - scratch the DBI/DBD possibility as my users in the cooks have this problem too and they are using an older module
19:12 chris actually it would need to be
19:12 cht i'll try that chris
19:12 chris oh no that oughta work
19:12 chris the other thing to check
19:13 cht k?
19:13 chris is if there isnt some way to get DBI to check the rows returned
19:13 cht i was thinking of that
19:14 cht one would think that you could
19:17 cht well, that change made rule 'a' not match, which is an improvement. now rule 'f' around 669 is matching
19:18 chris yeah you will have to do the same thing for all the if's
19:20 cht hmm
19:20 chris or at least
19:21 cht is this a bug or something that is only relevant in the unsupported 2.2.6+mysql5 scenario?
19:21 chris well i havent run into it before
19:21 cht i suppose the latter
19:21 chris so im guessing so
19:21 cht what's up with katipo and liblime?
19:22 chris russ, mason and I will be working for liblime after april 1
19:22 cht cool
19:23 cht the rest of katipo remains katipo?
19:23 chris yep, as far as im aware yep
19:23 cht exciting news, my friend
19:23 chris ahh heres what i have done
19:24 chris if (defined($result->{maxissueqty})) {
19:25 cht interesting
19:27 cht that change will not help with rule 'f', which has defined($result) && $result->{maxissueqty} ge 0
19:28 chris yeah
19:28 chris rule f looks ok
19:31 cht i'm going to get some caffiene and then come back and loojk at this fresh
19:32 cht back in a bit
21:48 cht well, i did some more investigation...
21:48 cht ahfter playing around with the if statements for a while...
21:48 cht (btw - DBI supports $sth->rows for row counts)
21:49 cht i am back to thinking that the logic of the TooMany sub in in koha 2.2.6 is just plain wrong
21:51 cht if you have your issue rules set so that an ADULT borrower can borrow 6 FICTION items and your * default borrower can only borrow 3 FICTION items...
21:51 cht you will always get the issuing warning when you lend out the 4th FICTION item to a borrower belonging to ADULT
21:52 cht this result, as far as I can tell, has nothing to do with the underlying DB type or version
21:54 cht try it on your install
21:56 cht if one leaves both the * row and the * column blank, this problem does not surface, OR if your set your default number of books as high as your highest borrower category
21:56 cht am i crazy?
22:02 cht scratch one earlier comment: leaving the * row blank causes borrowing limits of 0
08:58 toins hi #koha

| Channels | #koha index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary