IRC log for #koha, 2008-12-16

All times shown according to UTC.

Time S Nick Message
17:00 cfouts Can anyone point out to me where the "REPLACE INTO sessions..." statement occurs? I'm not having much success finding it.
17:25 ryan cfouts: must be done by CGI::Session?
17:29 cfouts I looked there, too, and didn't see anything in the CGI/Sessions tree. It may be in one of its dependencies.
17:32 cfouts I'm trying to figure out why it uses REPLACE instead of UPDATE. I'm guessing a lot of the table fragmentation (and slowness) that I see regarding the sessions table is the result of using replace.
17:33 acmoore cfouts: in previous projects using the same sessions module, we've put a timestamp on the sessions table and deleted rows not touched for some time.
17:34 acmoore otherwise, it seems to grow without bounds. Does Koha's grow like that?
17:35 atz acmoore: using replace would keep it from growing *in data* because it would only be 1/user.
17:35 atz but it could still grow *in disk*
17:35 atz (assuming the session is keyed on user)
17:36 cfouts yup, it grows without bounds.
17:36 acmoore perhaps it depends on what a "user" is. Do opac users get a session?
17:36 atz yes
17:36 cfouts yes, anon opac connections store session data.
17:36 cfouts which is how it gets so unruly.
17:36 acmoore that's the limitation we were hitting, too. One row per person hitting a website gets pretty big.
17:37 cfouts and the fragmentation slows things down quite a bit.
17:37 cfouts I've filed a feature-request bug for a timestamp.
17:37 atz yeah, i don't think there is any point to it... logically, we only need one anonymous user session
17:38 atz is there anything that an anonymous user can do that specializes their session?
17:38 cfouts but REPLACE INTO is slower than UPDATE, so I'm wondering what the rationale is behind using it.
17:39 atz cfouts: i think because it reliably destroys the data in the row, even if the update only writes a subset of fields
17:40 cfouts oh, interesting.
17:40 cfouts of course, there's only two columns in koha's use of it...
17:41 atz and a proposed third... but that's the idea anyway.  CGI::Session had to decide before knowing what our data looks like
17:42 acmoore cfouts: /usr/local/share/perl/5.8.8/CGI/Session/Driver/DBI.pm  appears to use "UPDATE", are you seeing "REPLACE" statements in the database?
17:42 atz acmoore: from CGI::Session code, we suppose
17:42 acmoore ah, /usr/local/share/perl/5.8.8/CGI/Session/Driver/mysql.pm
17:42 atz performance difference is likely dependent on storage implementation
17:43 atz innoDB vs. myISAM vs. dbd or whatever
17:43 cfouts oh, good find.
17:43 acmoore the mysql driver overrides the store() method from the generic DBI for some reason.
17:48 cfouts and the two columns are hard coded into the module, though cursory glance shows that one could transparently add a timestamp column.
17:50 acmoore I've done it (actually, with Apache:Session, but it's similar) with no problems. We let mysql auto-populate the timestamp and then a cronjob removed old ones periodically.
17:50 acmoore in fact, it's documented somewhere that you're supposed to be able to add columns, from what I recall.
19:19 owen atz around?
19:19 atz ?
19:20 owen Hi atz. I finally found the receipt printer we used to use at NPL
19:20 owen It's a Star SP2000
19:20 atz oh, cool.  
19:20 atz i'll add that to our doc....
19:22 owen It doesn't bode well that the link to their driver download page is broken
19:22 atz classic.  usually google has a better record of support docs/downloads for that old stuff...
19:25 atz thx for the info
21:00 owen logbot and newlogbot, together again!
21:26 acmoore I never realized that there was actually a "logbot". I thought newlogbot was the only one.
21:26 acmoore does he log to the same place?
21:27 chris nope logbot is the original
21:27 chris logs to a database at katipo
21:27 chris newlogbot is a copy of it, i got running when i was at liblime, which logs to a db there
21:28 chris and thats the one that the webinterface searches
21:31 acmoore ah.
21:32 acmoore so, I started using firebug a little more since I have some javascript that I'm writing now. I notice that many pages seem to have js bugs in them. Am I the only one seeing that, or is that kind of known?
21:32 chris its known
21:33 acmoore hmm. that's a drag. I wasn't sure if I was the one that caused the "addLoadEvent is not defined" error on this page or not. I guess I'm not.
21:42 atz acmoore: that's a bogus value in a syspref that snuck in (some custom dev's value)
21:43 acmoore ah. that's coming from my intranetuserjs syspref or something like that?
21:43 acmoore I think I recall now
21:43 atz right
21:44 acmoore geez. I thought I was going crazy after not being able to find that with ack, or grep, or even by opening about 4 dozen files in my editor.
21:44 acmoore thanks
21:45 atz we need an updatedatabase (or Datafix) to go purge it if it equals the crappy value
21:46 acmoore or something.
22:57 liz can you pull a report based on withdrawn status?
22:57 liz it doesn't seem to be in the report builder
09:05 chris hmmm

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