| 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/pipermail/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/flat/201106291934%28dot%2923089%28dot%29rsmogura%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 |
