| Time |
Nick |
Message |
| 07:29 |
|
sandbergja joined #evergreen |
| 08:05 |
|
sleary joined #evergreen |
| 08:13 |
|
BDorsey joined #evergreen |
| 08:30 |
|
mmorgan joined #evergreen |
| 08:34 |
|
kmlussier joined #evergreen |
| 08:34 |
kmlussier |
Good morning #evergreen! Happy Friday! |
| 08:34 |
kmlussier |
@coffee [someone] |
| 08:34 |
* pinesol |
brews and pours a cup of Honduras David Mancia, and sends it sliding down the bar to Christineb |
| 08:34 |
kmlussier |
@tea [someone] |
| 08:34 |
* pinesol |
brews and pours a pot of Organic Bangkok (Green Tea with Coconut, Ginger and Vanilla), and sends it sliding down the bar to jweston (http://ratetea.com/tea/harney/bangkok/2217/) |
| 08:35 |
kmlussier |
Ooh! That sounds good. |
| 08:35 |
kmlussier |
And, because it's Friday... |
| 08:35 |
kmlussier |
@dessert [someone] |
| 08:35 |
* pinesol |
grabs some Chocolate Pudding for dluch |
| 08:38 |
mmorgan |
Good morning! |
| 08:39 |
mmorgan |
Mmmm, that tea does sound good! Though I've been disappointed with coconut in green tea before. |
| 08:41 |
kmlussier |
I don't think I've ever had coconut in tea. |
| 08:46 |
|
mantis1 joined #evergreen |
| 09:06 |
|
sleary joined #evergreen |
| 10:03 |
berick |
oof, just found 300G of search.symspell_dictionary_updates. how to turn that off... |
| 10:04 |
|
sleary joined #evergreen |
| 10:04 |
|
smayo joined #evergreen |
| 10:06 |
|
dguarrac joined #evergreen |
| 10:25 |
|
tlittle joined #evergreen |
| 10:31 |
JBoyer |
berick, is that active data or bloat? Seems high. |
| 10:31 |
eeevil |
berick: if that is staying big, you've got something funky going on. with queued ingest, that should be cleared out at the end of each queue run, and withOUT queued ingest, that should be emptied at the commit of each transaction |
| 10:33 |
berick |
hm, k, it's possible i missed something in an upgrade. on 3.9, btw |
| 10:37 |
berick |
just cancled a COUNT(*) after it churned for a while. |
| 10:37 |
csharp_ |
not seeing unduly large data for that on our 3.10 system fwiw |
| 10:37 |
* berick |
nods |
| 10:56 |
berick |
looks like i missed an update for metabib.reingest_metabib_field_entries |
| 10:56 |
berick |
to call the reify stuff |
| 10:57 |
eeevil |
that will, in fact, do it, sir. :) |
| 10:58 |
berick |
cool, thanks eeevil |
| 11:00 |
csharp_ |
I would like to thank eeevil for all the good he does in the world |
| 11:01 |
berick |
heh |
| 11:02 |
|
briank joined #evergreen |
| 11:07 |
eeevil |
berick: jfyi, the purpose of that updates table (which, IIRC, is unlogged, so check that yours is!) is essentially the allow the normal case of "meh, nothing really changed in the dictionary" to be spotted and handled very quickly. it cuts the common-case performance impact down to very nearly 0, since the reification ends up reading, usually, a single DB page of data that's already in the OS cache, and then (after confirming that there's no |
| 11:07 |
eeevil |
effective change to words or word counts) clearing it out and not touching the dictionary itself |
| 11:08 |
berick |
i did see it's unlogged |
| 11:08 |
eeevil |
s/the allow/to allow/ ... coffee incoming |
| 11:20 |
kmlussier |
@coffee eeevil |
| 11:20 |
* pinesol |
brews and pours a cup of Honey Pot Espresso, and sends it sliding down the bar to eeevil |
| 11:21 |
eeevil |
kmlussier: thanks muchly! |
| 11:21 |
kmlussier |
eeevil: Anytime! I'm always happy to send fake coffee to people. |
| 11:26 |
csharp_ |
cybercoffee |
| 11:48 |
kmlussier |
cybercoffee++ |
| 11:57 |
csharp_ |
@quote search parties |
| 11:57 |
pinesol |
csharp_: 1 found: #46: "<_bott_> I am not a cataloger, but I speak..." |
| 11:57 |
csharp_ |
@quote 46 |
| 11:57 |
pinesol |
csharp_: http://xkcd.com/1739/ |
| 11:57 |
csharp_ |
@quote get 46 |
| 11:57 |
pinesol |
csharp_: Quote #46: "<_bott_> I am not a cataloger, but I speak enough MARC to be fun at parties" (added by gmcharlt at 11:43 AM, March 15, 2013) |
| 12:02 |
|
jihpringle joined #evergreen |
| 13:03 |
|
mantis1 joined #evergreen |
| 13:22 |
mantis1 |
weird behavior I noticed |
| 13:22 |
mantis1 |
for one item, there is a list of patrons under 'View Holds' in the Angular catalog |
| 13:23 |
mantis1 |
but for some reason some patrons aren't listed on there however on their accounts they do have holds placed for that item |
| 13:23 |
mantis1 |
I'm wondering if that's related to the item cataloged as an acquisitions item before changed over to the regular collection |
| 13:31 |
jihpringle |
mantis1: we saw that in 3.9 with a record that had 300+ holds |
| 13:31 |
mantis1 |
jihpringle: I'm wondering if it's because our barcodes for acq items end up being different than those replaced with real barcodes later on |
| 13:33 |
jihpringle |
I don't think would be the case for us, because of our reciprocal borrowing libraries are never supposed to place item level holds so all of our holds should have been title levels which should be unaffected by barcode changes |
| 13:36 |
jihpringle |
the only common thing we could find with the holds that weren't showing was that it was the older holds |
| 13:52 |
jonadab |
Item-level holds have a number of gotchas, yeah. The capability is useful for a variety of technical reasons, but it almost ought to be locked behind a "Yes I want this specific copy" confirmation or something. |
| 14:26 |
mmorgan |
mantis1: By "item" do you actually mean item hold? That is hold_type = C? We have seen visibility oddities with metarecord holds (hold_type = M). |
| 14:26 |
mantis1 |
mmorgan: yes |
| 14:26 |
mantis1 |
I did try replicating the issue on a test server but it does work as 'intended' |
| 14:26 |
mantis1 |
I let them know just to do bib level for now |
| 14:26 |
mantis1 |
just baffled by what could cause this specifically |
| 14:35 |
jeff |
if you look at the hold in question, assuming it is hold_type = 'C', does the hold's target point to a valid, non-deleted copy in asset.copy? Does the hold have an entry in reporter.hold_request_record? |
| 14:42 |
mantis1 |
jeff: ah good question I will check |
| 14:45 |
mantis1 |
jeff; yes to all |
| 14:46 |
mantis1 |
same target and all |
| 14:48 |
|
BAMkubasa joined #evergreen |
| 14:49 |
BAMkubasa |
without custom configuration, Evergreen can't expose patron stat cats via SIP, right? That's not part of the protocol or the way Evergreen implmeents it |
| 14:54 |
jeff |
BAMkubasa: I'm fairly certain you can enable that for specific stat cats, as an extension of sorts of the SIP protocol. |
| 14:54 |
BAMkubasa |
In the interface I see "SIP Field" and "SIP Format" but the "SIP Field" dropdown just has "No SIP Export" |
| 14:55 |
jeff |
BAMkubasa: it usually comes up in the context of using SIP for patron authentication, which I have strong personal feelings against, and think you should almost never do. ;-) |
| 14:55 |
BAMkubasa |
go oooonnnn |
| 14:55 |
BAMkubasa |
(I'm curious to know your thoughts) |
| 15:00 |
jeff |
that said, changing away from SIP once you've started to use it for that can be a large undertaking. |
| 15:00 |
jeff |
it may be that you need to manually create entries in actor.stat_cat_sip_fields, I'm not sure. |
| 15:00 |
|
mantis1 left #evergreen |
| 15:01 |
jeff |
ah, no. it's just that you need to define them under Server Administration before you can use them in Local Administration. |
| 15:01 |
jeff |
Actor Stat Cat Sip Fields |
| 15:04 |
jeff |
as for my thoughts on using SIP for patron auth with third parties, that may need to wait for another time. :-) |
| 15:08 |
BAMkubasa |
Thanks jeff |
| 17:01 |
|
mmorgan left #evergreen |
| 17:06 |
|
kmlussier left #evergreen |
| 17:36 |
|
Rogan joined #evergreen |
| 20:01 |
|
abneiman joined #evergreen |
| 20:04 |
|
gmcharlt joined #evergreen |
| 20:06 |
|
book` joined #evergreen |
| 20:10 |
|
jonadab joined #evergreen |
