| Time |
Nick |
Message |
| 00:28 |
|
jvwoolf joined #evergreen |
| 01:58 |
|
Stompro joined #evergreen |
| 02:47 |
|
genpaku joined #evergreen |
| 04:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:11 |
|
rjackson_isl joined #evergreen |
| 07:18 |
|
JBoyer joined #evergreen |
| 07:33 |
|
agoben joined #evergreen |
| 07:39 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
bos20k joined #evergreen |
| 08:43 |
|
collum joined #evergreen |
| 09:05 |
|
Jillianne joined #evergreen |
| 09:13 |
|
kmlussier joined #evergreen |
| 09:36 |
|
jwoodard joined #evergreen |
| 09:44 |
|
krvmga joined #evergreen |
| 10:25 |
|
jvwoolf1 joined #evergreen |
| 10:31 |
|
tspindler joined #evergreen |
| 10:48 |
Dyrcona |
So, about to do a pg_restore on a brand new server with 768GB of RAM 44 cores/88htt and PCIe NVME drives... What -j setting should I use? :) |
| 10:49 |
bshum |
Dyrcona: You left the hyperthreading on? Then go crazy :) |
| 10:49 |
Dyrcona |
Well, I want to run pg_bench after the load with ht on and then with ht off. |
| 10:52 |
JBoyer |
-j 40, though no matter how high a setting you use you're always going to wait on the metabib.real_fuill_rec index. |
| 10:52 |
bshum |
Haha, JBoyer++ # I said the exact same thing to Dyrcona separately :) |
| 10:53 |
Dyrcona |
JBoyer++ |
| 10:53 |
Dyrcona |
I thought some of that conversation was happening in here. :) |
| 10:55 |
JBoyer |
I skipped right past the HT part. I'd have probably picked something in the 70's just for funsies, but you're still only going to save a few mins overall. |
| 10:56 |
Dyrcona |
Yeah, and Josh Berkus reported performance hits with ht once you get past the number of actual cores. |
| 10:57 |
JBoyer |
Yeah, they're basically only 1/2 - 3/4 of a real core, some things are going to block in weird ways. |
| 10:57 |
JBoyer |
I did turn it off on my machines eventually. |
| 10:57 |
JBoyer |
But Proper Testing (tm) sounds interesting, I'm curious to see what you find. |
| 10:58 |
|
rlefaive joined #evergreen |
| 10:58 |
Dyrcona |
I've never used pg_bench before, so it might take me a few weeks to do proper testing. |
| 11:01 |
Dyrcona |
So, I'll try -j 40 just for kicks. :) |
| 11:31 |
dbs |
Am I wrong in thinking that each of the records linked to a conjoined item should show the call number / copy info? |
| 11:33 |
dbs |
For example, https://laurentian.concat.ca/eg/opac/record/3111007 shows it is linked to "Douglas-fir" but the corresponding record https://laurentian.concat.ca/eg/opac/record/3111012 doesn't show a call number, making it hard / impossible to find on the shelf |
| 11:33 |
dbs |
Might be a local customization I guess |
| 11:33 |
|
tspindler left #evergreen |
| 11:35 |
dbs |
Seems to work okay for http://spok.jabok.cuni.cz/eg/opac/record/16705 / http://spok.jabok.cuni.cz/eg/opac/record/19645 |
| 11:57 |
|
_adb joined #evergreen |
| 12:30 |
|
jihpringle joined #evergreen |
| 12:46 |
Dyrcona |
JBoyer bshum: It's on the last create index, now. That's pretty quick. |
| 12:54 |
dbs |
looks like our opac/parts/record/copy_table.tt2 template is idential to rel/2_10 stock, so maybe it's our unapi results or our Perl modules :/ |
| 12:54 |
Dyrcona |
Maybe that's how it works? |
| 12:55 |
Dyrcona |
I've not messed with conjoined items/records, so i don't really know. |
| 12:55 |
dbs |
the jabok.cuni.cz example shows how it should work, I think |
| 12:56 |
kmlussier |
There's a conjoined example in Concerto. I'll take a look. |
| 12:56 |
dbs |
I don't have a concerto example instance handy |
| 12:56 |
dbs |
thanks kmlussier! I saw you mention bibs 24 and 93 as examples in https://bugs.launchpad.net/evergreen/+bug/1486451 for a different matter |
| 12:56 |
pinesol_green |
Launchpad bug 1486451 in Evergreen "Conjoined items - wrong display of record details page" [Undecided,Confirmed] |
| 12:57 |
dbs |
(which btw I think we can just pull the CSS nowrap entry in question) |
| 12:57 |
kmlussier |
http://mlnc2.noblenet.org/eg/opac/record/15 |
| 12:58 |
* kmlussier |
is surprised she ever filed a bug related to Conjoined records. |
| 12:58 |
kmlussier |
Oh, I see. I was just commeting. |
| 12:58 |
kmlussier |
commenting even |
| 13:00 |
* kmlussier |
might just pull together a branch for that so that she can feel productive today. |
| 13:01 |
dbs |
kmlussier++ |
| 13:16 |
kmlussier |
One of these days, I'm going to accidentally push my own branch to master instead of the working repo. |
| 13:46 |
|
jvwoolf joined #evergreen |
| 14:11 |
dbs |
oh hey, EGCatLoader/Record has this nice loop where it collects peer_bib metadata for each copy on the current record |
| 14:15 |
dbs |
"request open-ils.search open-ils.search.peer_bibs 3111012" looks like it returns useful info too. hmm |
| 14:18 |
|
rlefaive joined #evergreen |
| 14:50 |
Dyrcona |
I suppose I should have optimized the server for restore instead of for production use. |
| 14:57 |
Dyrcona |
If an action_trigger.event_def has no granularity, does that mean it never runs? |
| 14:57 |
Dyrcona |
Specifically, I'm looking at 'money.payment_receipt.email' |
| 15:02 |
sandbergja |
So, what do I do if -- when I activate a PO -- I get the following EDI error message? create_acq_invoice_from_edi(..., ): unable to determine buyer (org unit) in invoice; buyer_san=; buyer_acct= at /usr/local/share/perl/5.14.2/OpenILS/Application/Acq/EDI.pm line 1040. |
| 15:04 |
Dyrcona |
I think I've answered my own question: Yes, if it is called directly which this one is. |
| 15:42 |
Dyrcona |
So, this is interesting: A money.payment_receipt.email event from yesterday is for a bill paid in 2015. |
| 15:43 |
Dyrcona |
rjackson_isl++ For looking at this, too. |
| 15:43 |
Dyrcona |
I checked the email logs and the email was sent to the patron yesterday. |
| 15:47 |
kmlussier |
Better late than never? |
| 15:48 |
Dyrcona |
heh. I think the patron can have the receipt sent from the tpac, but I'm checking on that. |
| 15:48 |
Dyrcona |
I may just look at all of the recent events to see. |
| 15:48 |
Dyrcona |
We only have 650 of these events since 2012. |
| 15:51 |
dbs |
well well well |
| 15:51 |
dbs |
If I add a dummy item to the record in question, then the peer bib copy also gets displayed. |
| 15:52 |
dbs |
Without that item, nothing gets displayed |
| 15:52 |
dbs |
Sounds like my "14:11 < dbs> oh hey, EGCatLoader/Record has this nice loop where it collects peer_bib metadata for each copy on the current record" might have been on target |
| 15:52 |
Dyrcona |
kmlussier rjackson_isl: I should have known this, but a patron can have a receipt emailed from the payment history in my opac. |
| 15:53 |
Dyrcona |
dbs++ |
| 15:53 |
rjackson_isl |
Dyrcona++ mystery solved then? ;) |
| 15:54 |
kmlussier |
Dyrcona: Yeah, now that you mention it, I think I knew that. I spent a bit of time looking closely at those screens a month or two ago. |
| 15:54 |
kmlussier |
dbs++ |
| 15:54 |
dbs |
(because of course our test Concerto records all have additional copies on them) |
| 15:58 |
kmlussier |
dbs: Yes, even the records for electronic resources have copies on them, which isn't ideal. I've been meaning to submit a patch to add e-resource records with just URIs. |
| 16:01 |
* dbs |
has only himself to blame for that |
| 16:03 |
kmlussier |
dbs: Blame for giving us a set of test records we can work with? |
| 16:15 |
|
jvwoolf joined #evergreen |
| 16:17 |
Dyrcona |
About email payment receipts: It appears also that is the only way to trigger the event at the moment. |
| 16:18 |
* Dyrcona |
smells an enhancement request coming in the near future. |
| 16:23 |
Dyrcona |
And, it looks like we missed a release note for 2.10 regarding that event. I'll have to do an update on the event defs' template fields. |
| 16:27 |
dbs |
Might be as simple as adding "IF ctx.foreign_copies; has_copies = 'true'; END;" to copy_table.tt2 |
| 16:30 |
pastebot |
"dbwells" at 64.57.241.14 pasted "foreign copies local change (dbs)" (13 lines) at http://paste.evergreen-ils.org/181 |
| 16:31 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 16:31 |
dbwells |
dbs: Just checking in for the first time today, ^^ is a patch we have locally. |
| 16:32 |
dbwells |
dbs: really the same idea as you state |
| 16:35 |
dbs |
thanks dbwells - also there's some jankiness in the trigger to update asset.opac_visible_copies (freaks out if there's already an entry when you try to add a conjoined item and makes it fail) |
| 16:36 |
dbs |
yeah that works. let's get that fix in so everyone can benefit! |
| 16:40 |
dbwells |
dbs: I would be happy to post a branch or to sign off on a branch. This was one of two local patches I had tagged as TOBUG. |
| 16:41 |
dbs |
dbwells++ |
| 16:41 |
* dbwells |
should make a branch for the other as well while it has his attention. |
| 16:46 |
kmlussier |
dbwells++ dbs++ |
| 16:46 |
dbs |
also fixing up the use of "copy_info.location" where we actually need bib.target_copy.location.name and the like |
| 16:55 |
dbwells |
dbs++ sounds good. We apparently didn't get that far. By the time we got things to show up, the librarian testing it out had moved on to something else, and it hasn't come around again for us. We have something like 100-200 bound volumes, so it naturally doesn't get much priority :( |
| 16:58 |
|
jvwoolf joined #evergreen |
| 16:58 |
dbs |
dbwells: bug 1703678 for your enjoyment |
| 16:58 |
pinesol_green |
Launchpad bug 1703678 in Evergreen "Conjoined items do not display without an extra copy attached to the record" [Undecided,New] https://launchpad.net/bugs/1703678 |
| 16:59 |
dbwells |
dbs: off-topic question, but something eating my time lately, do you guys do anything in the ilk of "institutional repository"? We've run a few test instances of various products over the years, but our only production collections are homegrown. We're getting ready to try out Invenio. Just curious. |
| 16:59 |
dbs |
have to go pick up a kid but will be back in a while -- and yes we have run DSpace in production since 2007 and it's a Java monster :) |
| 17:00 |
dbwells |
dbs: cool, I will maybe pick your brain about it sometime in the future. |
| 17:02 |
|
jvwoolf1 joined #evergreen |
| 17:05 |
jeffdavis |
Anyone know if there is a good brief explanation somewhere of why the search result count is just an estimate? |
| 17:06 |
jeffdavis |
I can mumble something about "extrapolating from superpages" but a more solid explanation would be handy if it's documented somewhere. |
| 17:12 |
|
jvwoolf1 left #evergreen |
| 17:16 |
|
Jillianne joined #evergreen |
| 17:17 |
kmlussier |
jeffdavis: It will be accurate in 3.0 |
| 17:17 |
kmlussier |
jeffdavis: Don't explain. Just give them hope for the future. |
| 17:21 |
jeffdavis |
heh yeah, I will definitely be emphasizing that part :) |
| 17:26 |
kmlussier |
jeffdavis: Are you explaining it to an end user or somebody more technical? If it's the latter, miker's report from here might help. http://georgialibraries.markmail.org/thread/4styymc3asioa5yl |
| 17:40 |
|
rlefaive joined #evergreen |
| 17:40 |
dbwells |
jeffdavis: I'm also curious about your use case, but decided to take a crack at it, for fun. I believe the following to be "close enough" :) |
| 17:41 |
dbwells |
jeffdavis: In current Evergreen, some search filters are too expensive to run over very large result sets, so search is run in stages. A first stage collects results, and a second stage filters those results, one portion at a time. If these filters remove, for example, half the original results from the first portion, then Evergreen estimates the total results from the first stage will be roughly cut in half once the whole set is filtered. This |
| 17:41 |
dbwells |
estimate is then adjusted as more portions are inspected when paging through the results. |
| 17:42 |
dbwells |
Maybe still too complicated, but it avoids talking about "rows" and "cursors" and other unmentionables :) |
| 17:42 |
jeffdavis |
dbwells: Thank you very much! That is much more cogent than my initial attempt. |
| 17:44 |
jeffdavis |
Probably the right amount of complexity actually - the original query came from an end user, but was forwarded to me by one of our support folks who needs a bit more of an explanation than "it's just an estimate," without getting into the finer details. |
| 17:45 |
jeffdavis |
kmlussier: thank you for that link too, that summary of current behavior is quite handy |
| 17:45 |
jeffdavis |
(in a section of the attached PDF) |
| 17:45 |
kmlussier |
dbwells++ |
| 17:46 |
dbwells |
I suppose I might edit "are too expensive" to "take too long". I'll stop now. Also, looking forward very much to seeing this become history. |
| 17:46 |
kmlussier |
My explanation has also always been accompanied by a reminder that Google does it too. |
| 17:46 |
kmlussier |
Not the two stage search. The estimated hits. |
| 18:35 |
|
b_bonner left #evergreen |
| 21:17 |
|
Jillianne joined #evergreen |
| 22:28 |
|
ningalls_ joined #evergreen |
