Evergreen ILS Website

IRC log for #evergreen, 2013-11-20

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
00:40 stevenyvr2 joined #evergreen
00:40 stevenyvr2 left #evergreen
07:02 timf joined #evergreen
07:34 akilsdonk joined #evergreen
08:05 eby joined #evergreen
08:11 misilot joined #evergreen
08:31 Shae joined #evergreen
08:36 mrpeters joined #evergreen
08:41 csharp looking at bug 1185865...
08:41 pinesol_green Launchpad bug 1185865 in Evergreen "Hold targeter taking a long time to run" (affected: 2, heat: 10) [Undecided,New] https://launchpad.net/bugs/1185865
08:41 csharp our hold targeter is taking a very long time, and I'm interested in upping the number of parallel processes (currently set to 2)
08:41 csharp what effects should I expect to see if I up that to 3 or 4?
08:42 csharp (aside from, presumably, a sped up targeting run)
08:42 mmorgan joined #evergreen
09:00 kbeswick joined #evergreen
09:03 ericar joined #evergreen
09:15 tsbere csharp: More load on storage and/or the DB, I suspect
09:15 tsbere csharp: MVLC runs that setting at 6
09:26 csharp well I just upped it to 3 and it went from 100 hold requests per minute to 59 per minute (or fewer)
09:26 csharp I guess other DB activity is slowing it too
10:00 ericar joined #evergreen
10:01 phasefx joined #evergreen
10:01 timhome joined #evergreen
10:01 mtate joined #evergreen
10:01 akilsdonk_ joined #evergreen
10:01 tfaile joined #evergreen
10:01 Callender joined #evergreen
10:01 BigRig_ joined #evergreen
10:06 rjackson-isl joined #evergreen
10:08 yboston joined #evergreen
10:08 collum joined #evergreen
10:08 phasefx_ joined #evergreen
10:09 ericar_ joined #evergreen
10:09 Callender_ joined #evergreen
10:09 BigRig joined #evergreen
10:09 timhome_ joined #evergreen
10:09 tfaile_ joined #evergreen
10:11 tater joined #evergreen
10:33 jboyer-isl Has anyone seen this before: We've got items showing up on the Holds Pull Lists to transit to other systems that haven't quite hit their age protection date. (Some will hit 6 months this afternoon, others tomorrow morning) It's like the date check is 1 day off somewhere, but not when you try to capture the hold (nothing is printed for those items)
10:33 jboyer-isl Launchpad's stellar search has failed me.
10:44 pinesol_green [evergreen|Liam Whalen] LP#1037171 Removed Expert Search paramters from subject links - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=6ec8bce>
10:44 pinesol_green [evergreen|Jason Etheridge] LP1093856 fix Fast Item Add with Z39.50 import - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=caf6322>
10:48 pinesol_green [evergreen|Jason Stephenson] Replace erroneous calls to $e->retrieve_authority_record($rec_id). - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=49a6922>
10:50 misilot left #evergreen
10:58 pinesol_green [evergreen|Mike Rylander] Enforce one-payment-per-xact-per-call - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=18812d0>
10:58 pinesol_green [evergreen|Bill Erickson] LP#1251774 exit and alert on multiple payments per xact - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=4159da2>
11:09 kmlussier joined #evergreen
11:13 kmlussier I have a question about Marc21expand880 in config.xml_transform. With that stylesheet, should we automatically be indexing the values from 880 fields into their corresponding title, subject, author indexes or does something need to be done to invoke it?
11:18 kmlussier Or maybe we need to add an index for MARC tag 245, subfield 6?
11:34 dMiller_ joined #evergreen
11:34 kmlussier Nope, that's not it.
11:36 dMiller__ joined #evergreen
11:53 dbs kmlussier: time to upgrade to MODS 3.4? http://list.georgialibraries.org/pipermai​l/open-ils-general/2011-March/004453.html
11:55 smyers_ joined #evergreen
11:55 * bshum groans inwardly
11:56 dbs http://markmail.org/message/q3btkewplkxxphdr never got a reply on how to actually use marc21expand880, and I don't think it's documented anywhere
11:56 kmlussier dbs: Does Evergreen already have the 3.4 stylesheet? If so, does that mean we just need to change our config.metabib_field entries to a format of mods34.
11:57 kmlussier dbs: Heh, I'm sitting here with the original author of that e-mail. :)
11:57 dbs kmlussier: MODS 3.3 is as far as we got in stock Evergreen, it seems.
11:58 dbs FWIW, MODS 3.5 is out now :)
11:58 kmlussier Yeah, I knew we were behind. Just wasn't sure how far.
11:59 dbs There's no MARCXML->MODS 3.5 stylesheet yet, though.
12:00 csharp MODS 3.3 is *so* January 15, 2008
12:01 dbs And we only use MODS 3.2 for the stock indexing definitions currently, there was some change to electronic resources IIRC in 3.3 that we never got around adjusting to.
12:02 dbs Coffeecode Consulting would be willing to do the work to bring stock Evergreen up to MODS 3.4 for one *MILLION* dollars. Any takers?
12:03 _bott_ joined #evergreen
12:03 paxed pity richard branson isn't sponsoring ...
12:04 dbs Coffeecode Consulting will throw Richard Branson off the edge of a cliff for one *BILLION* dollars
12:04 dbs (Price has to be high to fend off counter-bids from Sir Branson; but he'll end up having some crazy wingsuit or something anyway)
12:08 dbs bshum: does your groan indicate "Augh, _another_ reingest?"
12:09 bshum dbs: I was contemplating how much pain it would be to wait on that.
12:09 bshum But yeah pretty much
12:09 bshum I'm doing one this weekend anyways, as part of our incremental update to resync us to master.
12:10 bshum All those browse fixes and renumbering is going to take forever :(
12:23 gmcharlt /me offers up https://bugs.launchpad.net/evergreen/+bug/1253163 as both a warning and a plea for folks playing around with Pg 9.3 to comment
12:23 pinesol_green Launchpad bug 1253163 in Evergreen "authority indexes can fail on Postgres 9.3.0" (affected: 1, heat: 6) [Undecided,New]
12:23 ericar joined #evergreen
12:28 csharp gmcharlt: I was going to do a PG upgrade from 9.1 to 9.3 on a test server - I'll see if I can recreate
12:28 gmcharlt csharp++
12:30 dbs gmcharlt: you got past the xslt problem that dbwells and I were chewing on?
12:31 dbs https://bugs.launchpad.net/evergreen/+bug/1243023
12:31 pinesol_green Launchpad bug 1243023 in Evergreen "Browse catalogue titles are doubly escaped?" (affected: 1, heat: 6) [Undecided,New]
12:33 dMiller_ joined #evergreen
12:35 gmcharlt dbs: I've got to say that I've been less than impressed with the churn in XSLT and XPath handling in Pg since 9.1; can we resist the temptation to write a xml_transforms_the_write_way extension?
12:35 gmcharlt er, *right*_way
12:41 dbs gmcharlt++
12:42 gmcharlt dbs: and sadly ... at least for the xpath and xslt functions, I'm serious
12:46 dbs It's a bit flabbergasting that they don't take their application-breaking changes seriously on that front. Maybe it's a hatred of XML that is ingrained in relational database folks :)
12:47 gmcharlt or not enough perceived interest?  I don't mind joining the push for better functions in core, but I peceive that it would be longish road
12:52 dMiller_ joined #evergreen
13:04 mjingle joined #evergreen
13:07 dMiller__ joined #evergreen
13:09 dMiller_ joined #evergreen
13:12 kbutler joined #evergreen
13:12 jeffdavis http://pastebin.com/EkxNA1y5 <- has anyone run into this error before on ingest?
13:13 jeffdavis it's similar to bug 1116509
13:13 akilsdonk joined #evergreen
13:13 pinesol_green Launchpad bug 1116509 in Evergreen 2.3 "null SVF attribute value can break MARC record staging" (affected: 1, heat: 8) [Medium,Fix released] https://launchpad.net/bugs/1116509
13:13 jeffdavis but the error happens in a different function, and changing quote_literal to quote_nullable didn't fix it
13:16 eeevil jeffdavis: I suspect you have a normalizer that is returning NULL ... that's ConsideredHarmful(tm). do you have any non-stock normalizers that are mapped to any facet_field=true at pos <= 0?
13:20 dbwells dbs++
13:20 dbwells dbs: Just read your replies on pgsql-bugs, I think your analysis is spot on.
13:21 rjackson-isl joined #evergreen
13:21 eeevil jeffdavis: the output of this might be helpful: select m.field_class, m.name, n.name, n.func, map.params, map.pos from config.metabib_field_index_norm_map map join config.metabib_field m on (m.id = map.field) join config.index_normalizer n on (n.id = map.norm) where m.facet_field order by 1,2,6;
13:23 jeffdavis eeevil: yup, I do
13:24 jeffdavis hmm, actually none that are custom, just stock
13:29 stevenyvr2 joined #evergreen
13:30 krvmga joined #evergreen
13:31 krvmga in config.tt2 we can choose small, medium, or large for jacket_size images. where are "small" "medium" and "large" defined in the system?
13:32 jeff they are terms used by the added content handlers / providers, and depend on what each provider defines as "small", "medium", and "large"
13:33 krvmga jeff: interesting
13:34 eeevil dbs++ # indeed
13:34 dbs dbwells: thanks (fwiw!)
13:40 paxed #variables to use to remove parameters via mkurk
13:40 paxed urk!
13:41 * paxed giggles
13:53 jeff a pox on mailing list archive software that munges email-looking strings.
13:54 jeff 404, of course: http://www.postgresql.org/message-id/fl​at/201106291934%28dot%2923089%28dot%29r​smogura%28at%29softperience%28dot%29eu
13:55 ericar joined #evergreen
13:58 smyers_ joined #evergreen
14:03 j_scott joined #evergreen
14:03 mjingle joined #evergreen
14:06 bdl_john joined #evergreen
14:22 krvmga someone just reported to me that the place hold option in the opac disappears if, for example, there was only one copy of an item in the system, and it is now lost. the item can still be discovered in the opac but a hold can't be placed.
14:23 krvmga i hadn't seen this behavior and i've asked for their example and not gotten it yet
14:23 kbeswick_ joined #evergreen
14:23 krvmga is this a feature or an anomaly?
14:23 tsbere krvmga: "No holdable items" sounds like a good reason to hide the link
14:24 krvmga tsbere: i agree. does the system do it automatically?
14:24 krvmga i hadn't heard of this before.
14:25 tsbere krvmga: Yes, it does it automatically
14:25 krvmga TIL this
14:25 jeff new within the past year or two is a feature that hides the hold option when the system KNOWS that there's no possibility of placing a hold. it can still appear in other places where a hold attempt will fail.
14:25 tsbere krvmga: Other benefits of the code include the fact that records with no copies don't accept holds
14:26 tsbere But it doesn't check hold rules, and certain permissions in the staff client make the link show up 100% of the time
14:26 jeff but... i'm wondering about your example. if the only copy is indeed Lost, it shouldn't even be appearing in search results -- absent any local configuration otherwise.
14:29 tsbere jeff: Barring one permission being granted to staff the place hold link will vanish in the staff client too, and lost doesn't prevent staff searches from finding it
14:30 jeff tsbere: ah, i was thinking in a patron context for the lost example. thanks, that's probably it.
14:32 smyers_ joined #evergreen
14:33 smyers_ joined #evergreen
14:33 krvmga tsbere++
14:33 krvmga jeff++
14:36 tsbere krvmga: If you want I believe there is a config.tt2 setting you can change to show the links when there are copies. Though I don't see why you would want to, the link not being there is a really good indicator that they shouldn't be bothering ;)
14:44 krvmga tsbere: i can't think of a single reason i'd want to do this
14:44 tsbere krvmga: Because a group of librarians freaked out when the link wasn't there and convinced higher-ups to tell you to do so? Although that isn't really "want" as much as "need" at that point....
14:47 bshum Hmm, other than weird exception handling when returning an item, is there any other bad issues I should be thinking about before creating custom copy statuses?
14:47 bshum In particular, there's been some clammering for a status like "Claims Returned" which we set items to via library setting.
14:47 bshum Then make that type opac invisible, etc.
14:47 bshum Instead of using the existing "missing" option, which is opac visible it seems in our system...
14:48 jeff "like claims returned"?
14:48 jeff missing is opac visible for you?
14:48 * jeff checks stock and prod
14:48 bshum No that isn't normal
14:48 jeff got it.
14:48 bshum Someone decided it was a good idea to have lost and missing visible in OPAC
14:48 jeff oh.
14:49 plux joined #evergreen
14:49 jeff yeah, i'm not sure i'd agree with that. it might take some convincing. :-)
14:49 jeff i would however support making some things more "opac visible" to staff than patrons.
14:49 bshum We will be making lost materials opac invisible again with our weekend upgrade.
14:49 bshum But the question about creating a custom status for claims returned came up in a meeting yesterday.
14:50 pinesol_green [evergreen|Mike Rylander] Pulling in new version upgrade - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=cdfb7f0>
14:50 bshum So I'm thinking through all the potential issues.
14:50 jeff like, seeing missing copies in staff view seems useful vs needing to fire up holdings maintenance to see them.
14:50 jeff but i don't see much use in showing missing copies to patrons.
14:50 bshum Well, opac invisible still shows them in the staff client.  So in principle I agree with the defaults :)
14:50 bshum I just got overriden years ago in committees back before we were actually ON evergreen.
14:51 tsbere bshum: We have a possible desire for "aborted transits don't use reshelving" type stuff. >_>
14:53 jeff hrm. has jspac been removed yet?
14:53 jeff i feel like i should know this. i think the answer is "not removed yet".
14:53 * jeff looks
14:54 bshum I think the code is still there
14:54 jeff yep.
14:54 bshum Because bits and pieces have been used elsewhere
14:54 tsbere no guarantee of "functional" though ;)
14:54 jeff right.
14:54 bshum It certainly isn't functional as of the latest browsers
14:55 bshum I think I started trying to remove portions of JSPAC code at one point.  I think the big thing was removing some of the CSS stuff broke parts of the staff client.
14:55 bshum Where the dojo grids were using some CSS files among other things
14:56 bshum Might have been something with acquisitions maybe, where I moved some files and suddenly all the color coding went missing.
14:56 bshum Probably a worthwhile cleanup project at some point though.
15:02 ktomita joined #evergreen
15:19 * csharp confirms bug 1253163
15:19 pinesol_green Launchpad bug 1253163 in Evergreen "authority indexes can fail on Postgres 9.3.0" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1253163
15:19 csharp in my case it's PG 9.3.1 on Ubuntu 12.04
15:22 jeff hooray for tracking batch updates in a schema.
15:22 jeffdavis ugh, we have all the same config.index_normalizer entries as a clean install ... except that some of the primary keys are different :(
15:24 csharp jeff: how do you track them
15:24 csharp ?
15:25 csharp just backing up the tables?
15:30 jeffdavis I'm creating sample data based on our production environment -- clean db + concerto isn't close enough to prod for our dev/training needs, but a full prod snapshot is too big and raises privacy issues
15:30 jeff updating a bunch of copies, create a batch.acp table, insert into it based on a select with your criteria for the items to be updated, give your "batch" a name. then, do the update (optionally in small batches) with a RETURNING clause that is then used to update the batch.acp rows to indicate that they're done.
15:30 jeff let me know if that truncated before "they're done."
15:31 jeffdavis as a side effect I'm trying to identify places like this where we deviate needlessly from a clean upstream install (which is another big project of mine currently)
15:31 jeff jeffdavis: admirable on both counts.
15:32 jeff jeffdavis: keep in mind that in some cases, i believe the project as a whole has opted to not care about "same but for primary key" differences.
15:33 jeff jeffdavis: as maintaining the primary key across version upgrades and in the face of local changes can be tricky, and possibly with little to no benefit.
15:33 jeff jeffdavis: but that might not have been a question you had. sorry. :-)
15:33 jeffdavis no, that's good to know, thanks
15:33 csharp jeff: cool
15:33 csharp I'll have to check it out
15:34 csharp right now I'm doing backups in a separate table with the data I'm going to change, then I do 'UPDATE blah WHERE id IN <backuptablename>'
15:35 ktomita joined #evergreen
15:49 paxed is it possible to add a cost for patron holds? (say, either when the patron sets the hold, or when the hold is caught)
15:51 tsbere paxed: Not currently, to my knowledge, mainly because holds aren't billable transactions to begin with.
15:51 paxed that was one of the requirements over here.
15:57 jeff csharp: better example / more details here: https://gist.github.com/jeff/2dc488338c26626512a2
16:15 jeff it is entirely possible that there's another better way, but i've been using roughly that process for a number of things.
16:15 jeff and it can be handy when the eventual need to revert/modify a batch update comes along.
17:17 mmorgan left #evergreen
18:03 csharp jeff++ # thanks for sharing!
18:12 mrpeters joined #evergreen
18:37 stevenyvr2 left #evergreen
19:23 dMiller_ joined #evergreen
19:27 smyers_ joined #evergreen
19:32 mjingle left #evergreen
20:58 Callender joined #evergreen
20:58 tfaile joined #evergreen
20:58 BigRig joined #evergreen
20:58 phasefx joined #evergreen
21:02 tater joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat