Evergreen ILS Website

IRC log for #evergreen, 2015-08-25

| 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
05:00 pinesol_green Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html>
06:22 rlefaive joined #evergreen
07:35 mrpeters joined #evergreen
07:36 jboyer-isl joined #evergreen
07:55 rlefaive joined #evergreen
08:09 rlefaive joined #evergreen
08:32 mmorgan joined #evergreen
08:39 collum joined #evergreen
08:43 rlefaive joined #evergreen
08:55 maryj joined #evergreen
08:58 jwoodard joined #evergreen
09:00 akilsdonk joined #evergreen
09:01 yboston joined #evergreen
09:03 Dyrcona joined #evergreen
09:29 sarabee joined #evergreen
09:41 rjackson_isl joined #evergreen
10:01 rlefaive joined #evergreen
10:45 RoganH joined #evergreen
10:50 krvmga joined #evergreen
10:51 Christineb_away joined #evergreen
10:59 Bmagic @coffee
10:59 * pinesol_green brews and pours a cup of Guatemala Xeucalvitz, and sends it sliding down the bar to Bmagic
10:59 * Bmagic says mmmmmmmmm
10:59 mmorgan Good idea!
10:59 mmorgan @coffee
11:00 * pinesol_green brews and pours a cup of Sumatra Lake Tawar, and sends it sliding down the bar to mmorgan
11:00 Bmagic cheers!
11:00 mmorgan :)
11:00 Bmagic Happy Tuesday
11:00 Bmagic evergreen++
11:08 bshum mrpeters: Were you able to replicate Jesse's bug for addedcontent?  I'm still processing an upgraded system to test things out, but I didn't see any changes to the source code in that area for quite some time.
11:09 mrpeters i dont have a 2.8.3 system to test on to verify, but i saw something about a change to added content in release notes for 2.9 beta
11:09 bshum If not, it might be premature to tell them to file a bug on a potentially serious, but unconfirmed issue
11:09 bshum mrpeters: Yeah, that's for 2.9 / master, but it was not backported to rel_2_8
11:09 mrpeters interesting
11:10 bshum There haven't been any changes in that area since late 2014 or so when fixes for ContentCafe went in
11:10 mrpeters i did recently install a system using rel_2_8 from sometime about 2 weeks ago, so that has to be close to 2.8.3
11:10 mrpeters but they dont use Novelist
11:10 Dyrcona mrpeters: Covers are working just fine for me with the beta also.
11:11 mrpeters yeah, i was probably premature in telling him to file a bug -- should have asked to see his configuration
11:11 bshum Likewise, covers for Syndetics are fine for me on beta too
11:11 mrpeters likely is a syntax error there
11:11 bshum I actually didn't know that Novelist did covers
11:12 mrpeters line 67 is just simply $ac_handler->use;
11:12 mrpeters my $ac_handler = $ac_data->{module};
11:12 bshum It's possible that maybe something else could be awry too.  Maybe they messed up their templates for TPAC and it's pulling the wrong source (old ISBN-style instead of record ID way).
11:12 Dyrcona Their content handler isn't properly set would be my guess.
11:12 mrpeters which looks like it pulls from the opensrf xml files
11:12 bshum Or maybe their opensrf is using the wrong memcache
11:13 bshum And their stuff isn't being stored the right way
11:13 bshum Or permission errors in retrieving it
11:13 * berick notes there is no added content module for for Novelist
11:13 * Dyrcona was about to note that also.
11:13 bshum berick++ # good point too :P
11:13 Dyrcona berick++
11:13 berick if $ac_date == Novelist, it will def. fail
11:13 berick ac_data
11:14 mrpeters i bet thats it then
11:14 berick novelist stuff is template-only
11:14 mrpeters berick++
11:15 mrpeters berick: mind correcting me on the list?  he probalby doesn't need to post his config files after learning what you just told us
11:17 berick mrpeters: yeah, i'll respond
11:17 Dyrcona He may also be confused in thinking that Novelist provides content but doesn't.
11:18 Dyrcona IOW: He may think Novelist is configured to do that, but it isn't.
11:24 jeff ingest internals question, hopefully a simple one:
11:25 tsbere Is "simple" combined with "ingest" possible? ;)
11:25 jeff maybe. :-)
11:25 bshum I would like to ingest another cookie.
11:25 bshum The chocolate kind.
11:26 bshum With M&Ms preferrably.
11:26 jeff in (i think stock) config.metabib_field def 7 for personal author, a given bib has two entries in metabib.author_field_entry with field 7: one is the author name, the other is the author name with "creator" appended.
11:26 berick ingest == sarlacc pit
11:26 Dyrcona I was going to say, "There are simple questions. There are no simple answers."
11:27 jeff this field def has browse_field and facet_field set to true, and has a facet_xpath and browse_xpath which seems to explain why "creator" is stripped: //*[local-name()='namePart']
11:28 jeff it is unfortunately the only field def with both browse_field and facet_field set, so i can't compare against much.
11:28 tsbere jeff: The amount of "so you know where I am coming from" data before your question seems to have moved it out of "simple" already. :P
11:28 RoganH @coffee
11:28 * pinesol_green brews and pours a cup of El Salvador Pacamara Finca Los Alpes The Bank, and sends it sliding down the bar to RoganH
11:30 abneiman joined #evergreen
11:31 jeff tsbere: throw all that out then, i'll just skip to the question: "Why do I have two rows for field 7 in metabib.author_field_entry for many of my bibs, which differ only in that they lack a relator term? :-)
11:31 jeff "
11:32 bshum jeff: Do both entries show up when you reingest?
11:32 bshum I'm just wondering if there were weird shortcuts or perhaps partial reingests at play
11:32 * bshum hasn't checked his index setup to know whether double is normal or not
11:33 jeff select count(*), count as entries from (select source, count(*) from metabib.author_field_entry where field = 7 group by source) foo group by count order by entries;
11:33 jeff the large majority of our bibs have 2 entries for field 7.
11:33 jboyer-isl Re Novelist and covers from way back, they do re-sell B&T's ContentCafe for cover images as part of their offering, but you may have to pester them to actually get the CC login info.
11:34 jeff we have one bib with five entries for that field.
11:34 jeff hah.
11:34 jeff One Direction (Musical group)
11:35 jeff One Direction (Musical group) creator
11:35 jeff One Direction.
11:35 jeff One Direction. creator
11:35 jeff One Direction. creator One Direction (Musical group) creator
11:35 bshum fwiw, 7 is "corporate author" in my DB and 8 is my "personal author"
11:35 jeff bshum: oh, fun.
11:35 bshum So I'll start with, hmm :)
11:36 mrpeters berick++ thanks!
11:37 bshum And fwiw, changing your query from 7 to 8 to account for the different IDs, I do get 3 count for 5 entries, 1 with 4, lots of with 3 and loads more with 2.
11:37 bshum So, yes, it seems possible :)
11:38 jboyer-isl bshum, jeff, I also had a situation where an author field was out-of-whack that I re-adjusted during an upgrade (other fields were going to be clobbered if not, I think). I wonder if there are subtle differences in pre-X and post-X databases where X is between Indiana, Michigan, and Connecticut's go live dates?
11:38 bshum jboyer-isl: Probably in our base start versions of Evergreen meaning quirks with the seed data between major versions.
11:39 bshum Us being 1.6 or so when we started out.
11:39 bshum And you guys being 1.2 or 1.4?  :P
11:39 jboyer-isl I don't remember if we started at 1.2 or not. I think so.
11:39 * jeff nods
11:39 bshum So, it's not always guaranteed that the IDs will be exactly lined up.
11:39 jeff ME was 1.2.0.4 when we went live.
11:40 jboyer-isl The seed data id's shouldn't have been messed with though, even if it appears they were at some point.
11:40 jboyer-isl It makes upgrades more "exciting" than they need to be.
11:40 jeff jotting it down as "one more interesting quirk about our db that i think i already have on a similar list somewhere"
11:41 bshum jboyer-isl: Well custom metabib entries were moved up past 100 awhile back
11:41 bshum I think during one of the 2.0-2.1 or so eras
11:41 bshum Or maybe 1.6-2.0
11:41 bshum But all the stock stuff stayed where it was
11:41 bshum Or assumed to be where it was
11:41 bshum Maybe jeff has local tinkering :)
11:41 bshum Or ran an early version before things stabilized
11:41 bshum Or me
11:41 bshum I could have done something funky back in the day
11:42 bshum In any case
11:42 bshum Jeff, a cursory glance at our index, I can see what you describe
11:42 bshum Some entries with name, and others with name + creator, etc.
11:42 jboyer-isl bshum, I guess I can't rule out local funk at this level, but I really didn't think we were touching anything in there at that point.
11:42 jboyer-isl Oh well.
11:44 bshum I might expect that sort of result if the mods32 entry were looking for more than one kind of information
11:44 jeff anyway, looking at biblio.extract_metabib_field_entry seems to explain what i'm seeing.
11:46 bshum jboyer-isl: Out of curiousity, what is your config.metabib_field for IDs 7 and 8?  :D
11:46 * bshum wants to know if his database is the weird one
11:46 jeff bshum: stock defines it as you have, not as i have.
11:47 jboyer-isl bshum: 7 is corp, 8 is peronsal
11:47 jboyer-isl Peronsal sounds very French. A nice typo.
11:47 bshum Okay, just thought I'd check
11:48 jboyer-isl I also nudged that at one point because another id was going to collide in an upgrade (15 I think?) so we likely matched Jeff until then.
11:51 jeff so, so answer my question: for config.metabib_field definitions where browse_field is true and browse_xpath is not null, you will have multiple entries in the associated metabib.{CLASS}_field_entry table which likely will differ in value.
11:52 jeff this appears to include personal, conference, and other author.
12:02 ericar joined #evergreen
12:02 Dyrcona Stompro++ # A belated thanks for ded781a5dc2933867fd3cd41a7702bec4632fa9d
12:02 pinesol_green [evergreen|Josh Stompro] LP#1478123: fix leak of file descriptors by Apache workers - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=ded781a>
12:02 Dyrcona We'll see if that helps with our staff side's "Case of the Tuesdays."
12:05 buzzy joined #evergreen
12:06 jihpringle joined #evergreen
12:08 kitteh_ joined #evergreen
12:17 bmills joined #evergreen
12:30 mmorgan Anybody have a 2.9 beta install handy that can test the 90 day Mark Lost action trigger? Barcode CONC4000047 is one to test, it's checked out to user id 5 in the seed data.
12:31 mmorgan I'm testing lp 1331174 and can't get the 90 day Mark Lost action trigger to work at all, I'm assuming this works fine in beta, and it's either me or the code, but just want to make sure.
12:31 pinesol_green Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 5, heat: 22) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174
12:37 Dyrcona I have conerto data and the beta still loaded. I can take a look.
12:38 mmorgan Dyrcona: Thanks!
12:44 Bmagic Does anyone find it strange that it's possible that the master_record for a metarecord can point to a bib that is not a member of the group (metabib.metarecord_source_map)?
12:50 jlitrell joined #evergreen
12:50 Dyrcona mmorgan: It still work in the beta.
12:51 Dyrcona works, even. :)
12:51 mmorgan Dyrcona++
12:52 Bmagic mmorgan: are you testing with 2.9 beta?
12:52 mmorgan Thanks, makes me feel better that the problem is with the code or me. Not sure which of those is more likely ;-)
12:54 Dyrcona mmorgan: Make sure the event is enabled. It is off by default.
12:54 mmorgan Bmagic: No, kmlussier built a test server from the branch for the bug.
12:56 mmorgan Dyrcona: I'll recheck that. Seems like I've had it enabled/disabled and changed the intervals several times.
13:00 rlefaive joined #evergreen
13:00 Dyrcona I just enabled the trigger, ran action_trigger_runner.pl --process-hooks --run-pending, and the circulation on the copy mmorgan mentioned went to lost.
13:00 Dyrcona "Just" meaning all "I did was...."
13:01 Dyrcona Grr. Fingers don't want to cooperate today.
13:01 mmorgan Ok, thanks. I'll try exactly that on the test server.
13:27 ericar joined #evergreen
13:47 jihpringle_ joined #evergreen
14:17 rlefaive joined #evergreen
14:17 csharp_athens joined #evergreen
14:18 csharp_athens hello from a training in Athens, GA about Evergreen Community involvement!
14:19 * jeff waves
14:19 jeff hello!
14:19 berick howdy!
14:19 * bshum waves from the north
14:20 * tsbere waves between shaking his fist at Excel::Writer::XLSX
14:20 * jeff pictures csharp talking to his audience... "now, don't listen to this jeff guy..."
14:20 bshum Yeah, that jeff guy
14:20 bshum You gotta watch out for him.
14:20 * berick waves from a place in the South with North in its name
14:20 terran joined #evergreen
14:20 jboyer-isl We will NOT be displaying live logs during this training session.
14:20 bshum jboyer-isl++
14:20 jeff hi, terran!
14:21 terran Hi Jeff! Our audience is waving back.
14:23 terran bye!
15:31 Bmagic Does anyone find it strange that it's possible that the master_record for a metarecord can point to a bib that is not a member of the group (metabib.metarecord_source_map)?
15:32 jeff it can also point to a bib that is deleted, last i checked.
15:32 jeff in your experience, is it common for it to point to a non-member bib?
15:32 Bmagic I find 170 instances
15:33 Bmagic where the group contains non deleted bibs and the master_record is not any of them
15:33 Bmagic incoming query
15:33 Bmagic select * from metabib.metarecord a where master_record not in(select source from metabib.metarecord_source_map where metarecord=a.id) and id in (select metarecord from (select metarecord,count(*) from metabib.metarecord_source_map group by metarecord having count(*) > 1) as b )
15:41 jeff hrm. first metarecord i picked does not have any rows in metabib.metarecord_source_map.
15:42 Bmagic weird
15:43 jeff ah. inverted my sort. i think that was an ancient record.
15:43 Bmagic having count(*) > 1 should do it
15:46 jeff 2,348 or so for me.
15:46 jeff (different query)
15:46 jeff hrm. only 162 for your query.
15:47 jeff oh. master_record can be null.
15:48 jeff 1405 metarecords with null master_record
15:50 Bmagic hmm
15:50 Bmagic Does it seem wrong to you?
15:50 Bmagic How can the master record not be a member of the metarecord?
15:51 jeff regarding the metarecords with null master_record, the first example i looked at had a metarecord and two bibs in the metarecord_source_map, but both bibs were deleted.
15:52 Bmagic right, I was noticing that a great deal of my search results were deleted bibs, however, I found at least one example where the master record was pointing to a bib that really didn't belong to the others
15:53 jeff yeah.
15:54 Bmagic master record:  mig.missourievergreen.org/eg/opac/record/1363227    Member of the group:  http://mig.missourievergree​n.org/eg/opac/record/889739
15:55 Bmagic Same author but the titles dont line up at all. In fact the fingerprint on the master record is different than the fingerprints for the group
16:04 jeff i have one bib that is master_record on ten different metarecords. :-)
16:06 Bmagic yeah, weird right?
16:06 Bmagic what gives?
16:07 jeff only one of those ten metarecords has any entries in metabib.metarecord_source_map
16:10 jeff migrated records from the olden days in the case of the bibs that are master on 10 and 7 metabibs.
16:10 jeff er, s/metabibs/metarecords/
16:10 jeff :P
16:10 jboyer-isl Potential overlay issues maybe?
16:10 Bmagic after the bib is overlayed - shouldnt it get ingested?
16:10 jboyer-isl (i.e. the master record is changed so that it shouldn't be a member, but the case where "this record is the master" isn't fully handled?)
16:11 jboyer-isl (making this up as I go, so don't do anything without at least verifying SOMETHING. ;) )
16:11 Bmagic that could be, where the master is no longer a member of the group and the master record needs to be decided again
16:11 jeff another bib that is master on six metarecords has a metarecord fingerprint that seems to show an edit history -- the bib was modified in a way that changed the fingerprint.
16:14 jeff some of this will date back to open-ils.ingest (now dead and gone) and the days when spidermonkey javascript was generating bib fingerprints.
16:15 jeff and aside from the usual bugs that you expect to find in all software, metarecords in general were quite hidden for many years (after jspac deprecation and before metarecord support in TPAC)
16:18 Bmagic jboyer-isl: I tested this theory: Found a group of bibs where the master record is in the group. I updated the MARC of the master record to make the fingerprint be totally different. The master record remained in the group even with a different fingerprint!
16:19 Bmagic jboyer-isl: I decided to reingest the group, and that took care of it, suddenly the metarecord had a new master bib. However, the differently fingerprinted bib stayed in the group??....
16:19 jboyer-isl Delightful. (so to speak...) I was poking around git.evergreen... to see if I could see a hole in the remap logic, that is... slower than actually testing things.
16:19 jeff i've looked into this before, lightly.
16:20 jeff (well, "lightly" as in little useful output actually came of my digging)
16:20 Bmagic It looks like there is an issue with removing members of a group when the fingerprint becomes different than the group.
16:20 jboyer-isl Bmagic: could be a trigger that needs to look at NEW and OLD and is only looking at NEW, etc.
16:20 Bmagic Can holds get messed up too?
16:22 jboyer-isl Depends on what MR holds are pointed at, I don't actually have much experience with MRs at all. (we've had them disabled in the opac for some time, I think they've only recently been re-enabled)
16:22 jeff i don't think there is a well-defined / exposed / documented method for recalc/rematch of a set of bibs/metarecord set; there wasn't much exposure of 'this is this in another format' in the catalog until very recently; i think that a means of manually maintaining a metarecord set would be useful
16:22 jeff and with that last bit, you open the issue of "how to regen metarecords while still preserving manual adjustments" :-)
16:24 jeff anyway, i'd be interested in trying some theories on a fresh install AND on an existing dataset, to help determine which are current problems vs legacy mistakes possibly needing cleanup. both will probably become more important.
16:24 Bmagic is there already a bug on this?
16:25 jeff i think six or seven bugs have been discussed in the last half hour here. ;-)
16:25 jboyer-isl jeff: I think a method to force a rebuild of a group would be good, but I don't know about letting people muck about by hand. Seems like a process that should be possible to define well enough to handle entirely automatically, it just needs some help.
16:26 Bmagic https://bugs.launchpad.net/evergreen/+bug/953439 ?
16:26 pinesol_green Launchpad bug 953439 in Evergreen "metabib.remap_metarecord_for_bib has bad logic" (affected: 3, heat: 14) [Undecided,Triaged]
16:27 jboyer-isl I was just about to post that. Sounds related, if not the actual cause.
16:28 jeff found that one. it's probably related, but likely not the only issue here.
16:28 jeff bonus points: the bug isn't so old that the function and file referenced within the bug both still exist!
16:30 Stompro yboston++ thanks for the signoff
16:31 jboyer-isl I may have to poke around at this a little tomorrow, it's interesting, but not so interesting I can stay late to look at it. :)
16:31 jboyer-isl Bmagic: I'd say your example steps are good enough for a new bug even if it is related to an open one, there aren't any that are obvious dupes.
16:43 Bmagic how do I link to this conversation?
16:48 jeff i've updated bug 953439 (and marked it as Fix Released)
16:48 pinesol_green Launchpad bug 953439 in Evergreen "metabib.remap_metarecord_for_bib has bad logic" (affected: 4, heat: 18) [Undecided,Fix released] https://launchpad.net/bugs/953439
16:49 jeff Bmagic: this is a link directly to the line where you ask how to link to this conversation. :-) http://irc.evergreen-ils.org/​evergreen/2015-08-25#i_198689
16:49 jeff and this line links to itself: http://irc.evergreen-ils.org/​evergreen/2015-08-25#i_198693
16:50 Bmagic jeff: that bug was fixed in 2014?
16:51 jeff that particular logic issue was eliminated (because the relevant code was replaced as part of other work), yes.
16:51 Bmagic I created a new bug for this discussion
16:51 Bmagic https://bugs.launchpad.net/evergreen/+bug/1488655
16:51 pinesol_green Launchpad bug 1488655 in Evergreen "Metarecords are not being maintained properly" (affected: 1, heat: 6) [Undecided,New]
17:00 Bmagic I have a question for everyone. Has anyone tackled a claim of "Disappearing Holds" ? In other words: holds that were showing on a patrons account one minute and gone the next?
17:04 jeff probably.
17:09 mmorgan left #evergreen
17:16 Bmagic jeff: We are getting these reports frequently enough, it makes me think there really is a problem
17:17 jeff do you have any other details? what have logs shown? can you reproduce? are you auditing action.hold_request?
17:17 Bmagic jeff: I was able to compare all of the ID's from action.hold_request from a copy of our database 1.5 months old against production, and found that every ID was accounted for.
17:17 Bmagic jeff: action.hold_request has an auditor table? Not for me
17:18 jeff it is optional, you'd need to enable it. i don't remember if there's a handy helper or docs or if you'd just have to do it by hand.
17:19 Bmagic I guess I need to get that setup, because it's becoming a real thing
17:19 jeff showing on a patron and then gone oftentimes means cancelled or reset, if it's "showing as available then not available"
17:19 Bmagic jeff: yeah, they claim that it's not showing up under canceled either
17:20 jeff ah.
17:21 Bmagic haha, here is a quote from you "an uncancelled hold shows no sign at the database layer that it was ever cancelled or uncancelled. you can consult logs or you can enable auditing on action.hold_request, but i think that's it."
17:21 sandbergja joined #evergreen
17:21 Bmagic Dug that out http://irc.evergreen-ils.org/evergreen/2013-12-04
17:23 jeff hah
17:23 Bmagic so, I'm struggling to find documents on auditing action.hold_request
17:27 Bmagic Looks like it existed in 1.6
17:32 Bmagic so this worked  SELECT auditor.create_auditor ( 'action', 'hold_request' );
17:32 Bmagic at least it looks like it did on the surface
17:37 jwoodard Drained of energy, a haiku I cannot write, See what I did there
17:37 Bmagic ha
18:04 Bmagic later everyone!
18:04 Bmagic jeff++ jboyer-isl++
18:09 rlefaive joined #evergreen
19:23 jlitrell joined #evergreen
19:36 rlefaive joined #evergreen
20:15 rlefaive joined #evergreen
20:37 Bmagic mmorgan: Be sure that you have the event parameters set editor=1
20:37 Bmagic @later tell mmorgan  Be sure that you have the event parameters set editor=1
20:37 pinesol_green Bmagic: The operation succeeded.
20:57 RoganH joined #evergreen
21:07 Bmagic joined #evergreen
21:07 dluch joined #evergreen
21:15 rlefaive joined #evergreen
21:39 RoganH joined #evergreen
23:07 rlefaive joined #evergreen

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