Evergreen ILS Website

IRC log for #evergreen, 2015-12-18

| 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
04:02 geoffsams joined #evergreen
06:40 rlefaive joined #evergreen
06:54 mrpeters joined #evergreen
07:48 jboyer-isl joined #evergreen
08:02 rjackson_isl joined #evergreen
08:17 ericar joined #evergreen
08:49 mmorgan joined #evergreen
08:59 kmlussier berick: I was planning to review/probably merge bug 1312699 since Stompro signed off on it this week. Should I hold off now in light of bug 1527342 ?
08:59 pinesol_green Launchpad bug 1312699 in Evergreen "Editable Checkout History" [Wishlist,Triaged] https://launchpad.net/bugs/1312699
08:59 pinesol_green Launchpad bug 1527342 in Evergreen "Maintain patron reading history in a dedicated table." [Wishlist,New] https://launchpad.net/bugs/1527342 - Assigned to Bill Erickson (berick)
09:33 yboston joined #evergreen
09:41 maryj joined #evergreen
10:09 berick kmlussier: i'm a conflicted, but ultimately prefer we not merge it.  the UI parts of that code will be useful w/ my proposed changes.  all the SQL and other plumbing would have to be ripped back out, though.
10:09 berick s/a//
10:10 berick other considerations are that my code will almost certainly not make the 2.9 cut.
10:11 berick and so far I've only received feedback from jboyer-isl on my move-to-another-table proposal (via #1497335)
10:11 kmlussier berick: OK. I had been thinking it might make the 2.9, errr 2.10 cut, but if you don't think it will, I would be inclined to merge it.
10:11 kmlussier berick: I'll get feedback to you before I take off next week. :)
10:12 berick kmlussier++
10:12 kmlussier I was just reading up on it this morning.
10:14 berick hmm, i would really like to see us agree on some rough code poliices re: column widths.  239-character wide lines make me twitchy.
10:15 jboyer-isl kmlussier, berick: something else to keep in mind is that the mechanisms behind a feature don’t have to be static or even particularly long-lived. If the existing patch helps patrons and isn’t too large, it can always be replaced, even in the next release. (so long as user-facing changes aren’t too large either.)
10:16 jboyer-isl If it has to make a ton of changes in a lot of places though, I’d say berick
10:16 jboyer-isl ’s plan is the “right” one in the long run.
10:16 Shae_ joined #evergreen
10:16 berick i'm hoping if we merge, there will be no need for user facing changes.  it will all be plumbing.
10:16 jboyer-isl (which would mean don’t merge the existing, I’m having trouble English-ing today.)
10:17 jeff berick: i'd support kicking a change back for cleanup if it had long line lengths like that, even absent any formal guide
10:17 Shae_ joined #evergreen
10:18 jeff berick: I'd be less happy to see a mass-cleanup set of commits all over the place, but in the case of code that you're looking to change, a pre-change cleanup commit limited to the affected context?
10:18 kmlussier Huh, I thought was had a standard for line widths. But I'm not seeing it.
10:18 Shae_ joined #evergreen
10:19 jeff Avoiding "single commit that implements a change and a line length cleanup" is probably good also.
10:20 berick if anyone's curious, i'm talking about 2nd to last file changed in http://git.evergreen-ils.org/?p=worki​ng/Evergreen.git;a=commitdiff;h=7c325​b27634765f77b41f5b892b119cc602ce260
10:20 kmlussier berick / jboyer-isl: Yeah, my opinion is based on the fact that the editable checkout just barely missed the 2.9 cutoff because of a problem in the upgrade script. I hate making people wait another release for a feature once it's working as expected.
10:20 berick jeff: yeah, agreed we don't want to mix cleanup and changes
10:23 berick kmlussier: i'm OK with merging.  really it will just mean dropping a column
10:23 berick one of the functions changed in the commit will get dropped in my proposed code
10:23 berick sql functions, that is
10:24 berick and we'll have to check the hide_from_usr_history value as part of the migration to the new table, but that's easy enough
10:25 kmlussier berick++ #Thanks!
11:03 sarabee joined #evergreen
11:19 * tsbere wonders if anyone in the community would want his oclc number monitoring code >_>
11:20 Stompro tsbere, I would love to see it.
11:24 * tsbere goes ahead and reviews some of it for purposes of "did I hardcode anything sensitive?"
11:28 tsbere Stompro: http://pastebin.com/UPtzNTw7
11:33 jeff Ahh OCLC. Such conflicted feelings.
11:34 jeff I can't get them to return my inquiries for EZproxy support pricing.
11:34 tsbere jeff: I am hoping we skip EZproxy and just go with some of my apache module stuff. >_>
11:35 * jeff nods
11:38 tsbere Hmmm. Apparently I missed a trigger function.
11:38 * tsbere goes to update his paste with that
11:39 tsbere Stompro: I just added a trigger I had forgotten about to the paste there, if you were already looking.
11:44 Christineb joined #evergreen
11:45 jboyer-isl So we don’t go chasing a wild goose down a rabbit hole, is there any reason the “Last Receipt” function in standalone should not work normally? We’re getting reports of an error for util.print.simple on line 387 of JSAN.js. If it’s known not to work we’ll drop it, otherwise we’ll start digging.
11:49 tsbere We use standalone so infrequently I have no clue one way or the other.
11:52 Stompro tsbere, do you report OCLC holdings for MVLC as a whole?  I'm trying to understand if your code handles systems/branches that have their own OCLC holdings.
11:52 tsbere Stompro: We, as far as I know, only do global OCLC. If any of our members do their own I am unaware of it.
12:03 jihpringle joined #evergreen
12:06 jeffdavis1 joined #evergreen
12:08 Dyrcona joined #evergreen
12:09 jeffdavis1 left #evergreen
12:32 tsbere Stompro: If you want help adjusting my oclc code to include an org unit id (based on call number owning lib, maybe?) I can see about helping you with that at some point.
12:36 rlefaive joined #evergreen
12:38 csharp Stompro: in our case, OCLC has a translation table that maps org_unit.shortname to their codes
12:38 csharp so we send them a big PINES-wide file, and they know what to do with it
12:40 csharp jeff: OCLC was strangely non-communicative about pricing with one of our people recently too - took several months and multiple escalations to get a simple answer
12:40 csharp (not EZproxy in our case)
12:43 Stompro csharp, you do that for OCLC holdings withdraws?
12:43 csharp Stompro: no - we have the libraries handle their own deletions
12:43 jeff If you send the full file, why is there a need for deletions?
12:44 csharp jeff: I don't recall the specifics of why, actually ;-/
12:45 Stompro I was assuming he meant that for new additions the big file gets sent.
12:45 csharp yes, that's right
12:45 jeff Ah.
12:45 csharp for bibs added since the last upload
12:45 csharp er... holdings, I mean
12:46 jeff Sorry, I'm a little unfamiliar with how that works. We don't pay them enough money for them to accept holdings updates beyond "if you download this record from CatExpress, we add you to WorldCat as having it".
12:47 Stompro I think we have the additions worked out, its just the last copy part of it, where one system still has copies and the other doesn't that I'm trying to find the best way to deal with.
12:47 jeff And since that's far from comprehensive, nobody has voiced any interest in keeping up on withdrawals/deletions.
12:55 csharp Stompro: we're in the same boat - if you figure something out, I'd love to hear it ;-)
12:56 * jeff starts up a service to accept full extracts and maintain state, sending OCLC the required incrementals.
12:56 jeff With the revenue from that, perhaps we could afford to pay OCLC to update our holdings!
13:00 tsbere csharp: I don't think it would be too difficult to modify the code in my paste earlier to do per-ou (system? branch? ancestor at depth stuff works wonders...) tracking
13:10 csharp tsbere: ooh - I'll take a look
13:11 tsbere csharp: Just need to look at, say, the deleted flag on call numbers instead of bibs.
13:36 jeffdavis joined #evergreen
13:41 mdriscoll joined #evergreen
13:51 sandbergja joined #evergreen
13:51 jlundgren joined #evergreen
13:55 yboston heads up the Evergreen for academics group IRC meeting will start at 2 PM EST
14:01 yboston #startmeeting 2015-12-18 - Evergreen for academics monthly meeting.
14:01 pinesol_green Meeting started Fri Dec 18 14:01:17 2015 US/Eastern.  The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01 pinesol_green Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01 pinesol_green The meeting name has been set to '2015_12_18___evergreen_for_​academics_monthly_meeting_'
14:02 yboston The agenda can be found here http://wiki.evergreen-ils.org/doku.php​?id=evergreen_for_academics:2015-12-18
14:02 yboston please start introducing yourselves
14:02 Christineb #info Christineb is Christine Burns BC Libraries Cooperative / Sitka
14:02 yboston #info yboston is Yamil Suarez @ Berklee College of Music
14:02 kmlussier #info kmlussier is Kathy Lussier, MassLNC
14:02 yboston #chair kmlussier
14:02 pinesol_green Current chairs: kmlussier yboston
14:02 mdriscoll #info mdriscoll is Martha Driscoll, NOBLE
14:02 sandbergja #info sandbergja is Jane Sandberg, Linn-Benton Community College
14:02 jeffdavis #info jeffdavis is Jeff Davis, BC Libraries Cooperative
14:03 krvmga joined #evergreen
14:03 jlundgren #info jlundgren is Jeanette Lundgren, C/W MARS
14:03 krvmga #info krvmga = Jim Keenan, C/W MARS
14:03 jihpringle #info jihpringle is Jennifer Pringle BC Libraries Cooperative / Sitka
14:04 yboston Hello everyone. Today we will focus on the topic of reserves
14:04 krvmga a favorite!
14:04 yboston and kmlussier will lead the way with my help (if needed)
14:04 kmlussier Hi everyone! :)
14:04 sandbergja I'm excited!
14:05 kmlussier I thought it would be good just to start with a general discussion on how people are handling reserves with Evergreen since it doesn't have specific reserves functionality. What are you all using?
14:05 krvmga syrup
14:06 horganl joined #evergreen
14:06 mdriscoll syrup
14:06 krvmga the course reserves software created by art ryno
14:06 krvmga (sp?)
14:06 Christineb one of our libraries uses "bookbags" created by laurentian
14:06 sandbergja We are indexing professor name and course number in MARC fields for searching, and then using item buckets/copy editor to move 'em around and apply appropriate circmods
14:06 kmlussier Just a note that the Syrup course reserves system lives at http://git.evergreen-ils.o​rg/?p=Syrup.git;a=summary
14:06 kmlussier #link http://git.evergreen-ils.o​rg/?p=Syrup.git;a=summary
14:07 suzanne joined #evergreen
14:07 yboston we use a homemade reserves system using PHP and MySQL. It orignally was meant to work with Horizozn, but then we updated it to work with EG by using direct DB calls. It mostly just uses a copy's barcode
14:08 kmlussier Christineb: When you say you're using bookbags from Laurentian, what exactly does the code do to work with the bookbags in Evergreen?
14:09 kmlussier Also, I know there's a link to that code somewhere, but I can't recall where it is
14:09 jeffdavis The code is here (more or less): https://github.com/dbs/library
14:09 kmlussier jeffdavis++ #Thanks!
14:09 jeffdavis Based on my question to dbs the other day, Laurentian themselves are using a newer, Python-based homegrown app.
14:10 jeff dbs stated yesterday that Laurentian now uses https://github.com/dbs/course-reserves
14:10 kmlussier #link https://github.com/dbs/library
14:10 Christineb old post from Dan Scott - https://coffeecode.net/archives/250-Current-state​-of-academic-reserves-support-for-Evergreen.html
14:10 kmlussier #link https://github.com/dbs/course-reserves
14:11 jeffdavis The app that we are using is just a PHP + SQLite web app for recording & searching course name, instructor name, and a link to an Evergreen bookbag that contains the materials on reserve.
14:12 kmlussier Oh, I see. So the code creates the listing page, but then the bookbags themselves are just typical Evergreen bookbags. Is that right?
14:12 jeffdavis yep
14:13 kmlussier sandbergja: Could you explain your process a little more. The copies themselves are attached to the MARC record for the course rather than a record with bib information?
14:14 kmlussier Also, if other people have questions, feel free to ask them.
14:15 sandbergja Sorry, I wasn't clear.  We take an ordinary MARC record with bib information, and add course information to it in custom 9xx fields.
14:15 sandbergja Here's an example: http://libcat.linnbenton.edu/eg/opac/r​ecord/507772?expand=marchtml#marchtml
14:15 sandbergja 971 field contains our professor's name, and 972 contains the title of the course
14:16 kmlussier mdriscoll and krvmga can chime in, but in broad strokes, Syrup is a third-party system, but it tightly integrates with Evergreen so that it can look up instructors from the Evergreen database and then look up copies by barcode when adding them to the course.
14:16 jeffdavis sandbergja: Do you have a custom search index for those fields?
14:16 sandbergja jeffdavis: yes -- it was set up before my time
14:17 kmlussier sandbergja: Ah, I see now. When titles go off of reserves then, do you need to remove those local fields?
14:18 sandbergja Yes, in theory.  I suspect that we miss a few, though. :-)
14:18 kmlussier #info C/W MARS and NOBLE are using Syrup
14:18 mdriscoll sandbergja: are you able to get circulation stats by professor?
14:18 kmlussier #info A library in Sitka uses code from dbs that creates a course listing for reserves that are kept in bookbags
14:18 horganl I was just wondering if users are satisfied with the functions currently provided locally.  We are a noble library using syrup and like it pretty well except we would like it more integrated into evergreen
14:19 sandbergja mdriscoll: Yes, I was able to put together something in the reporter.
14:19 krvmga horganl: this is what we'd like to see as well
14:19 kmlussier #info Linn-Benton Community College uses MARC record with course information in local fields and manages copy parameters in buckets
14:20 kmlussier #info Berklee uses a homemade reserves system using PHP and MySQL
14:21 kmlussier Yes, to add on to what horganl is asking, are your local solutions working for you? What works well or doesn't work well? And, generally, would you like to see more baked-in functionality in Evergreen or are you okay with what you're doing now?
14:21 kmlussier Sorry, lots of questions in one post.
14:22 jeffdavis The one library using reserves at Sitka is reasonably satisfied AFAIK, but I think potential new members of the consortium would be happier with a more integrated reserves module (it's the kind of think post-secondary libraries ask about when they're looking at an ILS).
14:23 remingtron #info remingtron is Remington Steed, Hekman Library (Calvin College)
14:23 kmlussier jeffdavis: Yes, I agree that a more integrated reserves module would make Evergreen more attractive to academic libraries.
14:23 mdriscoll We use a seperate installation of syrup for each consortia member so from a sysadmin point of view it is cumbersome to do that, especially when it comes to updates.
14:24 remingtron #info Calvin College is using Syrup, with several customizations and bug fixes
14:24 sandbergja We're pretty happy with ours, but it does rely on a lot of staff time.
14:24 horganl And you can not look at the data at the item level from within syrup
14:25 kmlussier remingtron: I would love to see what you have for customizations and bug fixes sometime. For a future discussion.
14:26 remingtron kmlussier: sure, happy to discuss sometime.
14:26 krvmga mdriscoll: we do the same in C/W MARS. it can be a bit of a maintenance nightmare
14:26 jeffdavis Are there other limitations/missing features with Syrup that folks are running into?
14:27 jeffdavis (Not to get into a long discussion of bugs or whatever.)
14:27 kmlussier jeffdavis: What I hear most is we want something that better supports consortium the way Evergreen does and overall tighter integration.
14:28 mdriscoll We have run into issues with muli-branch libraries using one instance of Syrup.
14:28 kmlussier Usually, when there's a problem, it boils down to the fact that, as much as we've integrated it with Evergreen, it still is really a separate system.
14:28 jeff Can anyone elaborate what is meant by "tighter integration" or how you'd like to look at "data at the item level from within syrup"?
14:29 mdriscoll I would define tighter integration as using the existing evergreen tables wherever possible instead of duplicating copy data, user data etc.
14:29 kmlussier jeff: From my perspective, I would like to see course reserves baked into Evergreen using Syrup as its foundation.
14:30 kmlussier jeff: I think we could make integration tighter in other ways while keeping it a third-party system, but I think I would rather see it as something you can enable with a setting or two (or more).
14:31 jeff glossing over things like shared tables / reduced time to set up, what kinds of things are not possible currently?
14:33 horganl When you look at the item you can tell it is on reserve by the copy location but not for what course, instructor, or semester.
14:33 jeff Can you give any examples of the issues with multi-branch libraries, or the problems that have boiled down to Syrup being a distinct system?
14:33 jeff horganl: Ah! Thanks!
14:34 horganl If there needs to be a change to the circ modifier you can't go there directly from clicking on the link in syrup
14:34 kmlussier As mdriscoll mentioned, we're copying data over that is already in the Evergreen database. So as things get updated in Evergreen, they don't get updated in Syrup, which can be confusing for staff since they retrieved the data from Evergreen and don't understand why it doesn't get updated in both places.
14:35 mdriscoll Syrup is associated with a branch so when searching for a professor, it won't find users in another org unit.  This is a problem for one of our multi-campus libraries.
14:35 horganl One of the issues with Multi-branch libraries pertains to adding the instructor.  All of our instructors have to be entered in one directory even if they teach on the other campus
14:35 krvmga mdriscoll: we have the same issue
14:36 kmlussier jeff: Does that answer your questions?
14:36 horganl It becomes a training issue for staff....
14:36 jeff kmlussier: think so! thanks for obliging!
14:37 kmlussier jeff: np
14:37 jeff kmlussier++ mdriscoll++ horganl++ krvmga++
14:37 jihpringle do people have training resources they currently use for training staff that are publicly available of that they would be willing to share?
14:37 kmlussier During the hack-a-way, some of the MassLNC folks looked at what we thought it would take to do the work to get course reserves into Evergreen.
14:37 kmlussier #link http://wiki.evergreen-ils.org/doku​.php?id=scratchpad:course_reserves
14:38 sandbergja MassLNC++
14:39 kmlussier jihpringle: That's a good question. Does anyone have anything they can share now?
14:39 kmlussier Or maybe if something they can send to the list at a later time?
14:40 sandbergja jihpringle: here is the documentation that our circ staff uses for our custom-field workaround solution: https://docs.google.com/document/d/1t5X7E6DsIXow​BBv_6Q2s0PSdnfmB6Pkdqg1rSUgw2SY/edit?usp=sharing
14:41 sandbergja as I said, ours is a time-intensive process
14:41 jihpringle thanks sandbergja
14:41 kmlussier jihpringle: I don't think it's used for training, but artunit wrote up some docs for us on Syrup at http://git.evergreen-ils.org/?p=Syru​p.git;a=tree;f=docs;h=52dd2dfe05fc8a​d6892053080e29251658d246e7;hb=HEAD that can be useful for seeing how it works.
14:42 kmlussier Actually, it's nicely formatted here: http://git.evergreen-ils.org/?p=Syrup.gi​t;a=blob_plain;f=docs/syrup.html;hb=HEAD
14:42 jihpringle that's great for getting an idea of how it works, thanks
14:43 horganl Not sure our documentation is current we have changed how we do things since we came up.  One of the parts I really like about syrup is that we can control how the course and instructor appear for all records.
14:43 kmlussier What MassLNC is planning to do, hopefully with local resources, is to see if we can do the work to get course reserves as a baked-in part of Evergreen.
14:43 horganl In the past and Eng 101 course might be entered in multiple ways
14:43 krvmga masslnc++
14:44 Christineb masslnc++
14:44 kmlussier We were thinking it would entail two projects. One would be to create a reserves schema for course information and the interfaces around managing reserves.
14:44 jihpringle masslnc++
14:45 kmlussier But there is also a second project that we think will be useful to lots of sites, which is a way to store copy parameters and then easily revert them when an item is pulled off of reserves. We think this would be useful for display materials, summer reading, etc.
14:46 krvmga kmlussier: that would be useful
14:46 kmlussier Syrup already does this for us with our reserves materials, but I think its functionality extends beyond reserves.
14:47 kmlussier We have some draft requirements for the latter project, but they are already dated as I have some feedback to incorporate in them.
14:47 kmlussier But I'll share them to give you all an idea of how we envision it working http://masslnc.org/node/3181
14:48 kmlussier I had hoped to have more requirements available in time for this meeting, but I'm still working on them.
14:48 kmlussier We will be sharing them with the community as we go along, though, and I can report back at future meetings too.
14:49 kmlussier But before I leave off, I have a question. If there were just one thing that would improve your reserves workflow, whatever you are using, what would it be?
14:50 kmlussier Since we're looking at putting reserves in Evergreen, it would be good to see if we are making workflows easier for people.
14:52 jihpringle kmlussier: do you have an EG release you plan to target for the integration or is it too early for that?
14:52 kmlussier jihpringle: It's too early for that. Definitely NOT 2.10. :)
14:52 krvmga 2.12 sounds good. :)
14:53 kmlussier jihpringle: At this point, I need to finish up the functional requirements so that the tech people can look at them and give us a realistic estimate. But krvmga is probably close.
14:53 yboston so, we need to start talking about our next meeting
14:54 yboston and any action tiems that we need to identify
14:54 kmlussier yboston: Will we be doing a specific topic for the next meeting too?
14:55 yboston offically, I am not the one that decides that
14:55 yboston personally I wanted to suggest that we talk about reserves gain next time
14:55 jihpringle i really like the specific topic meeting, I think this one worked really well
14:55 yboston *again
14:55 yboston but I am open to finding another topic
14:55 jihpringle +1 course reserves
14:56 yboston also, do we want to meet again in January or wait for february?
14:56 krvmga yboston: i second that. in the meantime, everyone will have more of a chance to look at what is at the links given.
14:57 yboston so quickly, shoudl we target Janaury or february for next meerting?
14:57 jihpringle my vote is for february
14:57 mdriscoll I vote for February
14:57 kmlussier I have no opinion, but if it is January, can we do it after the 15th? That's when I'll be meeting with local folks about reserves.
14:57 yboston #action yboston will email the list with a copy of the meeting minutes
14:57 krvmga february +1
14:58 yboston could I get a volunteer to run a Doodle poll for February dates?
14:58 jihpringle sure
14:58 yboston I will email the  list witht he meeting minutes and update the wiki
14:58 yboston thanks
14:59 sandbergja joined #evergreen
14:59 yboston #action jihpringle will create a doodle poll for the next group meeting in February
14:59 kmlussier Thanks yboston!
14:59 yboston also, we seem to be in agreement on reserves as the topic?
15:00 krvmga yes, it seems so.
15:00 yboston I normally like to always check with the general list, but I want to give credit to those that make it to the IRC meetings
15:00 yboston #agreed the next group meetings topic will be reserves again
15:01 yboston any final comments or questions?
15:01 krvmga yboston++
15:01 jihpringle is there a list anywhere of the regular meeting days for othergroups, DIG, EOB etc. ? nothing is on the EG calendar for feb at the moment and I don't want to double book
15:01 krvmga kmlussier++
15:01 sandbergja kmlussier++
15:01 yboston let me look
15:01 kmlussier yboston++
15:01 jihpringle thanks
15:02 kmlussier jihpringle: EOB meets regularly (can't recall the day now) so I'm sure there's something scheduled.
15:02 kmlussier Developer meeting's on the 3rd
15:02 yboston I need to add the next Board meeting, there is also a standing academics meeting in the calendar that we don't have to stick to. (We could delete that automatic entry)
15:02 horganl left #evergreen
15:03 yboston the Board usually meets the 3rd Thursday of the month
15:03 jihpringle good to know, thanks
15:04 yboston #endmeeting
15:04 pinesol_green Meeting ended Fri Dec 18 15:04:08 2015 US/Eastern.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
15:04 pinesol_green Minutes:        http://evergreen-ils.org/meetings/evergr​een/2015/evergreen.2015-12-18-14.01.html
15:04 pinesol_green Minutes (text): http://evergreen-ils.org/meetings/evergr​een/2015/evergreen.2015-12-18-14.01.txt
15:04 pinesol_green Log:            http://evergreen-ils.org/meetings/evergree​n/2015/evergreen.2015-12-18-14.01.log.html
15:04 krvmga thanks, everyone! :)
15:05 krvmga sql/Pg/upgrade script question: all the scripts i've looked at have SELECT evergreen.upgrade_deps_block_check('0898', :eg_version); after BEGIN (where 0898 is the number at the beginning of the name of the script.
15:05 kmlussier Thanks everyone for sharing your reserves workflows! I found the info very useful!
15:05 krvmga i don't understand this line.
15:05 Stompro Has anyone added OCLC number search to your Z39.50 server?  I tried adding eg.scn to the search map in oils_z3950.xml, but I think there must be more too it, since that doesn't work.
15:07 jlundgren left #evergreen
15:08 yboston jihpringle: I just updated the calendar for February with the board meeting and DIG meeting
15:08 kmlussier jeff: One additional consideration that I forgot to mention during the meeting, beyond functionality, is that Syrup right now has a very small community of users, which can be challenging with an open source solution.
15:09 krvmga kmlussier: yes, a very small community of users
15:09 kmlussier AFAIK, the only sites using it are C/W MARS, NOBLE, Calvin College and Windsor. It makes it difficult for the software to grow, but also presents support challenges.
15:09 kmlussier Of course, artunit is always available to help us out when we're in trouble and has bailed us out a few times. :)
15:09 kmlussier artunit++
15:10 krvmga i know C/W MARS wants to step up more in this area
15:11 krvmga artunit++
15:11 jeffdavis krvmga: that SQL function checks config.upgrade_log to see if you've already run the current update.
15:11 kmlussier krvmga: Are you doing an upgrade script that will be part of code you're contributing to Evergreen?
15:11 kmlussier krvmga: If not, you don't need it.
15:12 krvmga kmlussier: no, we're just eliminating some lines in vandelay.overlay_bib_record
15:12 krvmga jeffdavis: thanks
15:14 krvmga per bshum's bandaid for 012.schema.vandelay.sql
15:14 krvmga commenting out three lines of code
15:16 pastebot "krvmga" at 64.57.241.14 pasted "upgrade to 012.schema.vandelay.sql" (72 lines) at http://paste.evergreen-ils.org/13
15:25 jeff kmlussier: I'm not sure which I like more -- a small open source project with four users, or a feature of a larger project with four users. :-)
15:26 kmlussier left #evergreen
15:26 kmlussier joined #evergreen
15:27 kmlussier jeff: Well, would it be four users then? If functionality is a baked-in part of the system, don't you think more people would be likely to use it than if it is something you have to install/maintain independently?
15:28 * mmorgan wonders how many users there are for the baked in Bookings functionality.
15:30 mmorgan We have a couple of libraries that use booking for a very specific purpose, but if it hadn't been baked in, their use certainly wouldn't have justified maintaining a separate installation
15:48 jihpringle mmorgan: we have a bunch of libraries try it but only one still using it that we know of - it just doesn't have all the needed functionality
15:52 jeff dbwells++ for bug 1527731
15:52 pinesol_green Launchpad bug 1527731 in Evergreen "Query for OPAC copies can be extremely slow" [Undecided,New] https://launchpad.net/bugs/1527731
15:53 jlitrell joined #evergreen
15:56 Stompro Should there be anything at http://open-ils.org/spec/SR​U/context-set/evergreen/v1 as mentioned at the SRU explain page http://egcatalog.larl.org/opac/extras/sru ?
16:01 * mmorgan reads through 1527731
16:02 mmorgan Do these copy queries get executed in a general OPAC search?
16:13 dbwells mmorgan: It is executed on the record detail page.
16:14 dbwells When using "next" and "previous", we would see fast, fast, fast, sloooow, fast, slooow, etc.
16:15 Stompro Is there a gui control to modify config.metabib_search_alias?  (getting closer to adding an index to SRU searching I think)
16:15 mmorgan dbwells: ok, makes sense. Thanks. Good catch!
16:15 mmorgan dbwells+
16:15 mmorgan Oops, make that dbwells++
16:15 dbwells :)
16:15 jeff Stompro: The current state of things shouldn't cause anything to break. Something could be put there, and I've seen some people put things at the URI used for identifiers...
16:17 jeff Stompro: The SRU spec doesn't make any recommendation other than that it is a string.
16:17 dbwells In practice, that query is a small part of the overall page load, so we would see either 2-3 second loads, or 9-10 second loads.  It was probably easier to notice now since our new server is generally much speedier.
16:18 jeff Stompro: the other identifiers use info:// uris, like "info:srw/cql-context-set/1/cql-v1.2"
16:19 jeff Stompro: You can see the info:srw entry in the info URI registry here: http://info-uri.info/registry/OAIHa​ndler?verb=GetRecord&metadataPr​efix=reg&identifier=info:srw/
16:21 Stompro jeff, thanks, I think I'm figuring it out. I was thinking that the link would have documentation, but I see now that it is more of an identifier.   Z39.50 maps -> SRU Index -> defined in the config.metabib_search_alias which refers to the system index.
16:54 mdriscoll left #evergreen
17:09 HoloIRCUser2 joined #evergreen
17:13 mmorgan left #evergreen
17:17 jeffdavis dbwells: as noted in the bug report, I think maybe 1527731 is the same issue as bug 1499086, for which I have shared a fix
17:17 pinesol_green Launchpad bug 1499086 in Evergreen 2.9 "Slowness/timeout on loading bookbags in OPAC" [Medium,Triaged] https://launchpad.net/bugs/1499086
17:18 jeffdavis my fix is your "proposed solution #3" I believe
17:20 dbwells jeffdavis: Yes, I think you are right.  Thanks for pointing this out!  Has it caused you folks any issues to run it this way?
17:21 bmills joined #evergreen
17:22 jeffdavis No, we've had it in production for a few months now and it seems fine. I did need to tweak my initial attempt; I'll need to double check to make sure that working branch contains all the tweaks.
17:23 jeffdavis I need to step away briefly but I will review later this afternoon and update the branch if need be.
17:24 dbwells jeffdavis++
18:00 Dyrcona joined #evergreen
18:05 Dyrcona joined #evergreen
18:20 jeffdavis ok, confirmed that working branch user/jeffdavis/lp1499086-bookbag-slowness has all necessary tweaks/bugfixes
21:58 artunit_ joined #evergreen

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