| Time |
Nick |
Message |
| 06:31 |
|
Callender joined #evergreen |
| 07:25 |
|
tater-laptop joined #evergreen |
| 07:57 |
|
remingtron joined #evergreen |
| 08:16 |
|
Dyrcona joined #evergreen |
| 08:23 |
|
akilsdonk joined #evergreen |
| 08:29 |
|
kmlussier joined #evergreen |
| 08:41 |
|
Bmagic joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:42 |
|
RoganH joined #evergreen |
| 08:45 |
|
ericar joined #evergreen |
| 08:55 |
|
jwoodard joined #evergreen |
| 08:58 |
|
mrpeters joined #evergreen |
| 09:07 |
jboyer-isl |
Has anyone seen symptoms like this on 2.5.x: Staff make edits to patron accounts (usually change barcode, passwd, and alert note - a recently migrated lib) and on saving the changes the staff client pegs a CPU core and locks up? (Post save, it's dying on the refresh) |
| 09:07 |
|
gsams joined #evergreen |
| 09:08 |
jboyer-isl |
We're really only seeing it at a single location (which implies local networking issues) but I've seen it happen with the same lib's staff + patrons off-site. |
| 09:09 |
jboyer-isl |
Sadly, there's nothing in the logs about an error or anything unusual and there's really no way to get anything out of the client at that point. (Good job doing blocking IO on the main thread, xulrunner. :( ) |
| 09:11 |
RoganH |
That's a new one on me. |
| 09:15 |
|
yboston joined #evergreen |
| 09:16 |
Bmagic |
We see similar behavior when the library has general packet loss to the server (internet connection) |
| 09:16 |
jboyer-isl |
We're assuming it's related to the fact that they're the latest migration, but it's seemingly random (It started out every couple of updates, now it's around once an hour or so) but nothing looks unusual. |
| 09:16 |
Bmagic |
Try ping -t google.com for 10 minutes and see how many are lost. It should be 0 |
| 09:18 |
|
kbeswick joined #evergreen |
| 09:18 |
jboyer-isl |
Bmagic: The client goes completely unresponsive in that case? I would have thought we'd have more of that if it was just packet loss causing it. |
| 09:18 |
jboyer-isl |
I'll have them try that out though. |
| 09:19 |
Bmagic |
The staff client goes unresponsive during packet loss periods |
| 09:19 |
Bmagic |
We see that in our libraries as well |
| 09:19 |
|
rjackson-isl joined #evergreen |
| 09:19 |
jboyer-isl |
Huh. I'll definitely get them on that then. Thanks for the lead. |
| 09:27 |
jeff |
that specific interface is a browser element, so it's going to behave a little differently than the xul interfaces when faced with adverse network conditions. |
| 09:28 |
jeff |
in a similar fashion to how the checkout functions vs marc import/export (vandelay) functions would react differently to said adverse conditions. |
| 09:33 |
jboyer-isl |
I'm looking forward to the web client then. At least when a modern browser is having connection issues you can still close it. ;) |
| 09:44 |
|
collum joined #evergreen |
| 09:44 |
|
kmlussier joined #evergreen |
| 09:51 |
|
mllewellyn joined #evergreen |
| 10:05 |
|
tspindler joined #evergreen |
| 10:13 |
|
RoganH joined #evergreen |
| 10:14 |
|
dluch joined #evergreen |
| 10:52 |
|
RoganH joined #evergreen |
| 11:02 |
Bmagic |
When using the report template tool, creating a report from the Hold Request base table. Is it even possible to output the author of the item on hold? I have attempted to add this column: bib record link-> Target Bib Record -> Indexed Author Field Entries -> value -> Raw Data. This results in an error: DBD::Pg::st execute failed: ERROR: table name "bla bla bla" specified more than once |
| 11:13 |
jboyer-isl |
Bmagic: You might try simplified record extracts rather than indexed author field entries, but it's hard to say what's going on with that error without the debug output of the report. |
| 11:14 |
Bmagic |
The debug output isnt there because the report fails |
| 11:22 |
Bmagic |
jboyer-isl: The simplified record extracts worked. I dont know why I didnt see that before! |
| 11:22 |
Bmagic |
jboyer-isl++ |
| 11:25 |
jboyer-isl |
Glad that took care of it. I think it's also possible when using that other link to end up with duplicate rows if there are more than one type of author on a record. |
| 11:43 |
Bmagic |
jboyer-isl: now I remember why I has having trouble. It's because i dont want author. I want Item Type (audiobook, electronic, etc) Either from the marc leader or I can settle for the 245$h |
| 11:44 |
Bmagic |
s/has/was/g |
| 11:50 |
kmlussier |
Reminder: dev meeting at 2 p.m. today. Add agenda items here: http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-06-12 |
| 11:51 |
jboyer-isl |
Well, there's Form and LitForm in Simple Record Extracts under Fixed Field Entry, but I'm not certain they're what you're after. |
| 11:56 |
dkyle |
Bmagic: sounds like you want Target Bib Record -> Fixed Field Entry -> Type -> Item Type Code |
| 11:58 |
Bmagic |
dkyle: I wish that would work. I just results in that same error again (when creating a report from the template) DBD::Pg::st execute failed: ERROR: table name "93841f606928c6502afb7db0161e4082" specified more than once at /openils/bin/clark-kent.pl line 217. |
| 12:02 |
dkyle |
Bmagic: what about using Target Bib Record -> Flattened MARC Fields -> Tag and Target Bib Record -> Flattened MARC Fields -> Subfield? |
| 12:05 |
|
hbrennan joined #evergreen |
| 12:07 |
Bmagic |
dkyle: I don't see that path exactly. I have this: Hold Request -> Bib Record Link -> Target Bib Record -> Flattened MARC Fields -> Subfield |
| 12:08 |
Bmagic |
And of course, when I add that, I get that same error about "specified more than once" |
| 12:14 |
dkyle |
Bmagic: I haven't really used reporter in years, but that error sounds kinda familiar, I'd go searching on that at this point |
| 12:27 |
Bmagic |
dkyle: Thanks for the lead, I am hammering on this and I will report back with findings |
| 12:29 |
dkyle |
Bmagic: u welcome. and take another look at your template, could be just specifying the same table more than once in a filter or such |
| 12:31 |
Bmagic |
One thing that doest make sense is: When adding the subfield to the output, is that just all subfields? It doesn't look like I can specify the output of a specific tag and subfield |
| 12:34 |
jboyer-isl |
Bmagic: You have to specify the field and subfield in the Basic Filters tab, meaning that you're likely to get results only when a record includes that field/subfield combination. |
| 12:35 |
|
RoganH joined #evergreen |
| 12:35 |
jeff |
unless you make use of nullability controls to force to a left join. |
| 12:35 |
jeff |
but i don't think that lack of that is causing the duplicate table error. |
| 12:49 |
Bmagic |
I was able to output what I needed in the report output after I changed the filters. Previously the filters were: Hold Request -> Hold Request Record -> Bibliographic Record -> Call Numbers -> Owning Library. and Hold Request -> Hold Request Record -> Hold Request::Requesting User-> Home Library |
| 12:49 |
Bmagic |
Those were bad |
| 12:50 |
Bmagic |
Instead I went with Hold Request -> Pickup Library and Hold Request -> ILS User:: Home Library -> Organizational Unit ID |
| 13:14 |
|
RoganH joined #evergreen |
| 13:24 |
|
ldw joined #evergreen |
| 14:02 |
kmlussier |
It's meeting time, but it doesn't look like we have much of an agenda. |
| 14:03 |
bshum |
kmlussier: Yeah I'm sorry about that. I have to add stuff |
| 14:03 |
bshum |
Been a busy day |
| 14:03 |
bshum |
Mine are more FYI announcement type things though. |
| 14:04 |
bshum |
I guess I can run it |
| 14:05 |
RoganH |
bshum++ |
| 14:05 |
kmlussier |
bshum++ |
| 14:05 |
bshum |
#startmeeting Evergreen Developer Meeting - 2014-06-12 |
| 14:05 |
pinesol_green |
Meeting started Thu Jun 12 14:05:07 2014 US/Eastern. The chair is bshum. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:05 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:05 |
pinesol_green |
The meeting name has been set to 'evergreen_developer_meeting___2014_06_12' |
| 14:05 |
bshum |
#topic Introductions |
| 14:05 |
bshum |
#info bshum = Ben Shum, Bibliomation |
| 14:05 |
DPearl1 |
#info DPearl1 is Dan Pearl from C/W MARS Inc. |
| 14:05 |
bshum |
Let's see who we've got and we'll see what we cover |
| 14:05 |
kmlussier |
#info kmlussier = Kathy Lussier, MassLNC |
| 14:05 |
RoganH |
#info RoganH = Rogan Hamby, SCLENDS |
| 14:05 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (Calvin College) |
| 14:06 |
remingtron |
#info remingtron is Remington Steed, Hekman Library (Calvin College) |
| 14:06 |
bshum |
#link Agenda: http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2014-06-12 |
| 14:06 |
bshum |
I'll add more to it as we go |
| 14:06 |
dkyle |
#info dkyle Doug Kyle, Grand Rapids Public Library |
| 14:08 |
|
jscott joined #evergreen |
| 14:08 |
bshum |
Okie dokie |
| 14:08 |
bshum |
So as others fill in, feel free to announce yourselves. But we'll move forward. |
| 14:09 |
bshum |
#topic Past action items from last meeting |
| 14:09 |
bshum |
#info eeevil After 2.6.0 is cut, eeevil to publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan. |
| 14:09 |
eeevil |
#info eeevil = Mike Rylander, ESI |
| 14:09 |
bshum |
I assume that's still ongoing, but as a related note on that plan, I think I'd like to take this moment to discuss dbwells' notes on the dev list about upgrade paths. |
| 14:09 |
eeevil |
bshum: not yet. I plan to jump on dbwells' thread |
| 14:09 |
eeevil |
heh |
| 14:10 |
bshum |
#link dbwells' plan: http://markmail.org/message/tl5d3tnupq2istx7 |
| 14:11 |
bshum |
I just linked to the thread dbwells started on the dev list to talk about new approaches for upgrade strategy. |
| 14:11 |
gmcharlt |
#info gmcharlt = Galen Charlton, ESI |
| 14:11 |
bshum |
I'm tardy with my own reply, but I'm curious to see what we can hammer out as we move forward this summer. |
| 14:12 |
bshum |
#help Get more responses and ideas sent to list about future Evergreen upgrade strategy. |
| 14:12 |
dbwells |
Anything I do with regards to that thread will be short-term, hopefully. |
| 14:13 |
bshum |
Sounds reasonable. |
| 14:13 |
bshum |
dbwells++ for getting the ball rolling |
| 14:13 |
bshum |
Okay |
| 14:13 |
bshum |
#topic OpenSRF release |
| 14:14 |
bshum |
gmcharlt: Springing this on you, but do you have any thoughts about 2.4 work? |
| 14:14 |
gmcharlt |
bshum: aiming for a release after ALA |
| 14:14 |
bshum |
#info gmcharlt aiming for an OpenSRF 2.4 release after ALA |
| 14:15 |
gmcharlt |
main thing I'd like at this point is more testing of the websocket work by berick |
| 14:15 |
bshum |
#info Get more testing of the websocket work started by berick, see https://bugs.launchpad.net/opensrf/+bug/1268619 and others |
| 14:15 |
pinesol_green |
Launchpad bug 1268619 in OpenSRF "WebSockets Gateway and JS Library" (affected: 1, heat: 6) [Undecided,New] |
| 14:16 |
bshum |
Sounds like a good thing. |
| 14:17 |
bshum |
Okay, we'll follow up on that after ALA, but in the meantime, folks should check out the bug and other announcements to help start testing the upcoming work for OpenSRF. |
| 14:18 |
bshum |
Thanks for the update gmcharlt++ |
| 14:18 |
bshum |
#topic Evergreen maintenance releases |
| 14:19 |
dbwells |
#info 2.5.5 and 2.6.1 are out |
| 14:19 |
bshum |
The next date on the calendar for that is 6/18, do we want to stick to that or perhaps shift things slightly? |
| 14:20 |
bshum |
dbwells++ # doing the release dance |
| 14:21 |
dbwells |
I haven't managed to hit the dates yet, but I think pushing it back will just give me a new date to not hit. |
| 14:21 |
bshum |
I'm not sure how much review we're able to get done over the next week, but I feel like there's a lot of things on the pullrequest tagged towards 2.6.2 |
| 14:22 |
bshum |
Oh, fewer than I thought actually |
| 14:22 |
bshum |
https://bugs.launchpad.net/evergreen/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field. |
| 14:22 |
bshum |
milestone%3Alist=66077&field.tag=pullrequest+&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on |
| 14:22 |
bshum |
Gah, sorry |
| 14:22 |
bshum |
Just 7 |
| 14:22 |
* bshum |
will try shortening his URLs next time) |
| 14:23 |
dbwells |
I think it is best for maintenance releases to come out as on-time as possible, and whatever is in, is in. A month really isn't that long. |
| 14:23 |
bshum |
Okay, so if dbwells, you'd prefer to stick with the current timeline, let's make our best effort to meet that then. |
| 14:23 |
dbwells |
sounds good |
| 14:23 |
dbwells |
I'll get it right, this time! |
| 14:24 |
bshum |
#info Next maintenance releases due out on 6/18/14. Core committers and other reviewers, please make best effort to look at bugs and sign-off on work. |
| 14:24 |
bshum |
Okay |
| 14:25 |
bshum |
#topic Evergreen 2.7 update |
| 14:25 |
dbwells |
To be clear, I consider 6/18 to be the date when I branch and make the preview build. |
| 14:25 |
bshum |
#info Today (6/12) was the new date to assign first milestones for major work to be considered for 2.7. |
| 14:26 |
bshum |
I see that we have lots of stuff lined up nicely for 2.next. |
| 14:27 |
berick |
i still need to add an LP for a minor-ish thing. will do so shortly. |
| 14:27 |
bshum |
berick: I told myself that I can expect an LP for first web client work whenever you're ready. I think everybody generally expects that to happen when it happens. |
| 14:28 |
bshum |
Hopefully not a surprise ;) |
| 14:28 |
berick |
heh, no, not a surprise. i could use some feedback on how best to structure it though.. one LP first sprint 1 or broken out, etc. |
| 14:29 |
berick |
but, yeah, still a good bit of work to do before anything is done-ish |
| 14:30 |
bshum |
Hmm, I think one bug per sprint sounds like it might not be unreasonable as a starting point. We may find that individual bugs may be necessary to track specific issues though? |
| 14:31 |
bshum |
I guess it depends on how comfortable you are separating the parts of the sprint into separate bugs |
| 14:31 |
bshum |
We could track the whole sprint as a blueprint and link it to each bug separately. |
| 14:31 |
bshum |
I guess it's more about how the final code will be presented. |
| 14:32 |
berick |
well, for the initial round of testing, i'm considering maintaining maybe a simple list somewhere. there will be /lots/ of little things. opening LP's for each would be cumbersome, imo. |
| 14:32 |
dbs |
#info dbs, Laurentian University |
| 14:32 |
berick |
after that's settled down, though, then we can leverage LP in the usual fashion |
| 14:33 |
bshum |
Sounds reasonable to me. |
| 14:34 |
bshum |
Any other thoughts for berick at this time? |
| 14:34 |
bshum |
berick: Or any specific areas you would like to mention about the web client work? |
| 14:34 |
bshum |
berick++ by the way, for sending out regular updates on the ongoing efforts |
| 14:34 |
bshum |
(and getting feedback) |
| 14:34 |
dbs |
berick++ |
| 14:34 |
RoganH |
berick++ |
| 14:34 |
berick |
lately i'm in the trenches, so no super interesting udpates to provide |
| 14:34 |
kmlussier |
berick++ |
| 14:34 |
dbwells |
berick++ |
| 14:34 |
berick |
just working thorugh UIs |
| 14:35 |
berick |
aw, shucks |
| 14:35 |
jeff |
berick++ |
| 14:35 |
jeff |
and greetings. |
| 14:35 |
berick |
i am curious if we want to try to roll any of this out with the next release |
| 14:35 |
berick |
as a preview type thing |
| 14:35 |
dbs |
tpac-style |
| 14:35 |
bshum |
Next release meaning 2.7? |
| 14:35 |
RoganH |
I'm in favor of that. |
| 14:36 |
berick |
it will mean we really need to get in the websockets testing |
| 14:36 |
dbwells |
+1 to including as a preview |
| 14:36 |
bshum |
+1 to preview |
| 14:36 |
berick |
bshum: right, next meaning 2.7 |
| 14:36 |
berick |
it's pushing it close |
| 14:37 |
bshum |
Well, let's see how you feel before beta cutoff then |
| 14:37 |
berick |
remind me of the date, plz? |
| 14:37 |
bshum |
Which is August 7 |
| 14:37 |
berick |
thanks |
| 14:37 |
bshum |
(had to look it up myself) |
| 14:38 |
berick |
fortunately, the code is almost entirely standalone and outside the realm of everday EG code |
| 14:38 |
bshum |
Okay, sounds like a reasonable goal to try for ;) |
| 14:38 |
berick |
there's a few IDL changes and, IIRC, 1 minor API change |
| 14:38 |
berick |
so, the big thing really is just the websockets stuff |
| 14:39 |
berick |
as far as disrupting the status quo goes |
| 14:39 |
|
hbrennan joined #evergreen |
| 14:39 |
dbwells |
berick: Granting you 4 hours of sleep per night, you still have 1000+ hours before the beta cutoff, plenty of time |
| 14:39 |
jeff |
dbwells++ |
| 14:39 |
bshum |
Heh |
| 14:39 |
hbrennan |
bshum: Your guidance, nor my actions yesterday, were the cause of the checkout breaking! |
| 14:40 |
hbrennan |
*not your guidance |
| 14:40 |
hbrennan |
Whatever, stupid english grammar |
| 14:40 |
* berick |
takes 100 10-minute naps 60 times |
| 14:41 |
bshum |
Okay, anything else for this topic before we move on? (next up, brief mentions about ongoing activities) |
| 14:41 |
bshum |
Okay |
| 14:42 |
bshum |
#topic The Hack-A-Way potential location |
| 14:42 |
RoganH |
The 2014 Hack-A-Way poll is open until next Friday the 20th at midnight EST. |
| 14:42 |
RoganH |
#info hackaway poll http://doodle.com/qzzfem72ixntitnv |
| 14:42 |
RoganH |
Right now Rock Hill, SC being sponsored by the York Public Library is in the lead |
| 14:43 |
RoganH |
After a location is chosen I will poll attendees to determine the dates. |
| 14:43 |
RoganH |
Any questions at this point? |
| 14:43 |
kmlussier |
RoganH++ |
| 14:43 |
bshum |
RoganH++ |
| 14:43 |
berick |
RoganH++ |
| 14:43 |
|
krvmga joined #evergreen |
| 14:44 |
RoganH |
If it's Rock Hill the hotel will probably be the Holiday Inn (its just been remodeled and is very nice) right off I-77. Cheap, easy to get to. |
| 14:44 |
bshum |
Going beyond the location, I think that it's worth noting that last year's hack-a-way we did have some offsite participants using Google hangout. But we hope to see as many show up in-person as possible to hack together ;) |
| 14:44 |
RoganH |
It's about 20 minutes from the Charlotte Airport. And York will probably cater lunch 2 or 3 days. |
| 14:45 |
|
jeffdavis joined #evergreen |
| 14:45 |
RoganH |
Agreed. And I'm going to look at how we can do more with Google hangout but I don't doubt that being there in person has distinct advantages. |
| 14:45 |
RoganH |
Still, I want to be as inclusive as possible with the Hangouts because just not everyone can make the trek. |
| 14:45 |
|
jeffdavis joined #evergreen |
| 14:46 |
bshum |
We'll see what happens as details unfold. In the meantime, fill out the poll and spread the word! |
| 14:46 |
dbs |
as a hangout participant last time, I thank you :) |
| 14:46 |
RoganH |
That was my first real playing with Hangouts. I've come to love them and think we can do a better job with them this year. |
| 14:46 |
RoganH |
I use them a lot now. |
| 14:47 |
bshum |
Any other questions for RoganH before we move on (next up, notable mentions, aka some short announcements time) |
| 14:47 |
berick |
hackaway will just be us building raspberry pi cameras ;) |
| 14:48 |
RoganH |
berick: pre-hackfest event :) |
| 14:48 |
bshum |
#topic Other Mentions |
| 14:48 |
berick |
it's on! |
| 14:48 |
bshum |
#info dbs brought up phabricator as a potential replacement for LP, etc. |
| 14:49 |
bshum |
#link Wikimedia blog post about their move: http://blog.wikimedia.org/2014/06/10/on-our-way-to-phabricator/ |
| 14:49 |
dbs |
fwiw, I consider that a very low priority item, just putting a pin in it for the next time the "GAWD I HATE LAUNCHPAD" discussion swells up |
| 14:49 |
bshum |
While I don't have the tuits right now, this has sparked some interest for me, and I wanted it on the notes. |
| 14:50 |
dbwells |
I haven't delved deeply, but I think Phabricator looks pretty nice. |
| 14:50 |
dbwells |
Other than being PHP, but I can get over it. |
| 14:51 |
bshum |
Heh, yeah, well, LP hate comes up every once in awhile ;) |
| 14:51 |
bshum |
dbs++ for keeping his eyes open |
| 14:52 |
dkyle |
#link change floating back to bool: https://bugs.launchpad.net/evergreen/+bug/1319919. wonder if there is agreement on this? |
| 14:52 |
pinesol_green |
Launchpad bug 1319919 in Evergreen "upgrading to 2.5+ can break copy templates" (affected: 6, heat: 32) [Undecided,New] |
| 14:52 |
RoganH |
Any idea how cumbersome migrating from LP to Phabricator would be? Some casual googling brings up a lot of bugzilla to Phabricator links but not much for LP. |
| 14:53 |
bshum |
RoganH: That was my first question too, I haven't dug up enough yet. Maybe we do the LP->bugzilla->Phabricator dance then? (he says half joking) |
| 14:53 |
RoganH |
That's not a -1, just throwing out the question. Some quick searches don't make an informed opinion on my part :) |
| 14:53 |
bshum |
Certainly worth someone looking more closely at when we get more time. |
| 14:54 |
bshum |
Anywho, that's all I had for this segment. The last thing on the actual agenda was talking about new development, but we can take a moment to talk about what dkyle just brought up too. |
| 14:55 |
bshum |
Well, actually, let's stick with the time, given what we have left. |
| 14:55 |
bshum |
#topic Feedback for New Features under development |
| 14:56 |
bshum |
#info Conditional Negative Balances - https://bugs.launchpad.net/evergreen/+bug/1198465 |
| 14:56 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 12, heat: 52) [Wishlist,Confirmed] |
| 14:56 |
kmlussier |
I don't have much to say on this topic because I know dbwells is planning to take a look at it this week. But I just want to say that it would be great if we could get eyes on this issue so that we can set a path forward. |
| 14:56 |
kmlussier |
There are 11 people who have clicked the "me too" link in LP, which is a lot for this community. So it seems like this code is important to a lot of people, and I would hate to note see a solution by the time 2.7 is released. |
| 14:57 |
kmlussier |
I'm going to reiterate (again) that I still prefer the original approach and would love to work with Dyrcona to dust off that branch and fix bugs that were found. |
| 14:57 |
kmlussier |
But MassLNC is committed to working with the community to get this code working in some fashion. I just want to make sure it's done in a way that doesn't add confusion for the end user or for the sys admins who are troubleshooting problems. |
| 14:57 |
kmlussier |
That's all I have to say at the moment. Well under the 2 minutes that bshum just gave me. :) |
| 14:58 |
* dbs |
hopes to get back to Dyrcona's RDA bug real soon now too |
| 14:59 |
dbs |
Ah, LP 1304462 but it looks like bshum is on that |
| 14:59 |
pinesol_green |
Launchpad bug 1304462 in Evergreen "Add 264 tag values to Record Summary" (affected: 3, heat: 18) [Wishlist,In progress] https://launchpad.net/bugs/1304462 - Assigned to Ben Shum (bshum) |
| 14:59 |
bshum |
For the record, when this work slipped away during 2.6 due to differing opinions by reviewers, I really hoped to make this a priority for 2.7. So, speaking for myself as RM, I'd welcome any input on that bug to help forge our path forward. |
| 14:59 |
RoganH |
kmlussier: A thought. At this point the LP entry for conditional negative balances is an impressive wall of text. And I'm guilty of not going through it carefully since the first few posts. |
| 15:00 |
RoganH |
kmlussier: Can this be simplified for discussion or does it have enough important nuance that it needs to be dug through? |
| 15:00 |
kmlussier |
RoganH: I can certainly simplify it, but I have to admit I'm a bit biased on the whole discussion. |
| 15:01 |
kmlussier |
My concern is that this bug ultimately has big impacts on end users, and they aren't really seeing the nuances of the different approaches. |
| 15:01 |
RoganH |
kmlussier: I'm willing to read through it all. I agree it's important. I'm willing to do so and post about it but with the caveat that I might need correction if I miss a nuance. |
| 15:02 |
RoganH |
(Actually that seems likely that I will.) |
| 15:02 |
kmlussier |
For end users (not the devs), it might also be useful to have side-by-side screenshots of what happens. But, although I have done numerous screenshots in my last round of testing, I don't have much for what the original approach did. |
| 15:03 |
|
shadowspar joined #evergreen |
| 15:03 |
|
berick joined #evergreen |
| 15:03 |
|
JLDAGH joined #evergreen |
| 15:03 |
jeffdavis |
A summary post about it to open-ils-general or open-ils-dev would be useful, I think - dunno if our support folks have looked at the bug so far. |
| 15:03 |
bshum |
Oh boy, netsplits. |
| 15:04 |
kmlussier |
I'm happy to work on a summary post and even post it here as a check against potential bias. |
| 15:04 |
kmlussier |
But it will have to wait until next week. Vacation day tomorrow. |
| 15:04 |
bshum |
kmlussier: That sounds reasonable. Plus it'll give dbwells some time to work on his reply he mentions in the last comment. |
| 15:05 |
bshum |
I'm going to add action items for both of you on this and we'll follow up next meeting ;) |
| 15:06 |
bshum |
#action dbwells to review and comment on conditional negative balance bug: https://bugs.launchpad.net/evergreen/+bug/1198465 |
| 15:06 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 13, heat: 56) [Wishlist,Confirmed] |
| 15:06 |
bshum |
#action kmlussier to work on summary of bug to list and gather more feedback to move forward |
| 15:06 |
dbwells |
I've said a lot in the thread, and don't want to speak too much for eeevil, but we're taking the approach of preserving/extending the existing functionality rather than replacing. I know some of the complaints are UI related, but I think that can all be secondary to ironing things out on the conceptual level. |
| 15:08 |
bshum |
Okay, we're over our time (though we did start late). |
| 15:08 |
eeevil |
dbwells: in short, I agree. however, I'm not going to have the tuits in the short term (you mentioned this or next week) to get heavily involved |
| 15:09 |
bshum |
Thanks for sticking with me on this loosely formed agenda. We'll aim to do better next time. |
| 15:09 |
eeevil |
bshum++ |
| 15:09 |
DPearl1 |
bshum++ You did just fine |
| 15:09 |
bshum |
I'm going to close this meeting, but suggest continuing any conversations for those who stick around. |
| 15:09 |
jeff |
bshum++ way better than that guy who ran the last few meetings ;-) |
| 15:09 |
kmlussier |
bshum++ #Making up your own agenda. :) |
| 15:09 |
bshum |
#endmeeting |
| 15:09 |
pinesol_green |
Meeting ended Thu Jun 12 15:09:42 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:09 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-06-12-14.05.html |
| 15:09 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-06-12-14.05.txt |
| 15:09 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-06-12-14.05.log.html |
| 15:09 |
bshum |
I do want to say something about rec_descriptor |
| 15:10 |
dbwells |
bshum++ |
| 15:10 |
bshum |
And the concept of "preserving functionality" but also being mindful of the potential performance issues. |
| 15:10 |
bshum |
I have to write up all the stuff I've gone through this week, but I really think that we need to look more closely at how we fix that area if we want 2.6 to be more successful as more folks upgrade into it. |
| 15:10 |
dbwells |
eeevil: No problem, I think we'll all just keep chipping away at it until we get there. |
| 15:11 |
eeevil |
bshum: absolutely. your pathological hold case is a good example to look out for. did you try the "wide select clause" route, by chance? |
| 15:12 |
bshum |
eeevil: I haven't gotten to dig too deeply at solving it yet. I just did the horrible hacky thing and ripped it out to get moving more quickly for the moment. |
| 15:12 |
bshum |
I think I'm still wrapping my mind around how everything is organized now. |
| 15:13 |
bshum |
eeevil: Also, humor me because I'm a novice, but what's a "wide select clause" route look like? :) |
| 15:13 |
eeevil |
sorry, I didn't use that wording before |
| 15:13 |
eeevil |
basically, |
| 15:15 |
eeevil |
select r.id, (select min(value) from ...flat_attr where attr = 'item_form' and record = r.id) as item_form, ... FROM metabib.record_attr_vector_list r; |
| 15:16 |
eeevil |
repeating that select clause subselect for each of the mrd fields |
| 15:17 |
eeevil |
(excepting title and author ... I'd just leave those blank for mrd, but you could pull them from metabib.record_sorter) |
| 15:17 |
bshum |
metabib.rec_descriptor doesn't currently have title/author in it I think |
| 15:18 |
eeevil |
oh? good! :) |
| 15:18 |
eeevil |
record_attr did |
| 15:18 |
dbwells |
eeevil: bshum: I've been poking at this too, based on bshum's instigation. I can give that a try as well and report back. |
| 15:18 |
eeevil |
dbwells: cool, thanks. should be much faster than view->view->hstore->view |
| 15:19 |
kmlussier |
I've been tied up in meetings all week and have just been catching up on this discussion. The rec_descriptor issue that bshum raised, where is that causing performance problems? I know reports was one of the areas bshum was poking at, but I'm confused as how it's related to holds. |
| 15:19 |
eeevil |
that's really just for reports, though. step 2 is use attr_flat instead |
| 15:20 |
jeff |
kmlussier: it can also slow down the hold permit checks at check when opportunistic hold capture takes place |
| 15:20 |
eeevil |
kmlussier: for cases where we have to test 100 holds and find that none will work for this copy, it's adding too much time to checkin. for normal cases where we only need to test a couple, it's not noticeable |
| 15:20 |
jeff |
kmlussier: given an item on a bib with many holds, but the item is not eligible for any of the holds, it can lead to timeouts at checkin |
| 15:21 |
bshum |
Well, it's noticeable all the time if you care about milliseconds (like our new library using a SIP sorter for checkins) does. |
| 15:21 |
kmlussier |
So this is when the retarget checkin modifier is being used? |
| 15:21 |
jeff |
(not eligible due to say, age hold protection and all holds being remote) |
| 15:21 |
jeff |
kmlussier: no |
| 15:21 |
jeff |
kmlussier: at checkin unless no-op checkin is used |
| 15:21 |
eeevil |
bshum / dbwells: a shim we could use in the interim would be an mat-view shaped like mrd, populated at ingest (via a separate, later trigger, for easier removal) |
| 15:21 |
bshum |
But yeah, for the majority of items / uses it's not a big deal. |
| 15:21 |
kmlussier |
Ah, I see. |
| 15:21 |
kmlussier |
And, yikes, that's not good. |
| 15:22 |
Dyrcona |
Thing is, we're on the same code as bshum and we don't see it. |
| 15:22 |
eeevil |
a mat-view would solve the reports problem too |
| 15:23 |
bshum |
eeevil: I wondered if that would help with overall performances. And wondered if this was a PG 9.3 vs. 9.1 issue with how fast it was reading indexes or whatnot |
| 15:23 |
bshum |
I did see that materialized views was something that seemed new to 9.3 |
| 15:23 |
eeevil |
bshum: it'd be a plan difference, not an index reading thing ... I'd be surprised, but it's possible |
| 15:23 |
jeff |
bshum: and before 9.3, you just maintain them with a trigger (there are a few in Evergreen already) |
| 15:24 |
|
tater-laptop joined #evergreen |
| 15:24 |
eeevil |
oh, and I mean a mat-view that /we/ create. like the copy visibility table |
| 15:24 |
eeevil |
not a CREATE MATERIALIZED VIEW thing |
| 15:26 |
bshum |
eeevil: Well I don't have conclusive proof of issues with PG 9.3, but it's one of the few things that separate me and Dyrcona right now. |
| 15:26 |
bshum |
Though I am starting to wonder about our crazy holds/circ rules |
| 15:26 |
|
ldw joined #evergreen |
| 15:26 |
bshum |
And maybe just us finally hitting some tip point where it's breaking things. |
| 15:27 |
eeevil |
well, dataset size, hardware, tuning, all that will change query plans |
| 15:27 |
kmlussier |
Is there anyone else on 2.6 who is seeing this? |
| 15:27 |
bshum |
I imagine the number of holds too. |
| 15:27 |
bshum |
At least for that particular problem |
| 15:28 |
eeevil |
kmlussier: fwiw, bshum is the first report /I/ know of, out of several 2.6's I'm near |
| 15:28 |
Dyrcona |
We're on 9.1, that's the biggest difference between and Bibliomation. |
| 15:29 |
kmlussier |
eeevil: I'm just concerned because, as you know, we have networks that have circ/hold rules that are probably as crazy as bshum's. |
| 15:29 |
Dyrcona |
They also have about 5x times as many hold_matrix_matchpoint entries. |
| 15:29 |
kmlussier |
And if there is a potential performance issue, it's going to hit them. |
| 15:29 |
eeevil |
it's not the number of rules |
| 15:29 |
Dyrcona |
No, I don't think it is, either. |
| 15:29 |
eeevil |
it's the number of holds that a copy cannot fill, even though it's on the potentials list |
| 15:29 |
Dyrcona |
I was gonna say 7,200 isn't that many earlier. |
| 15:30 |
kmlussier |
So the more restrictive you are with your holds policies, the more likely you are to see this problem? |
| 15:30 |
eeevil |
so, age protection and transit distance restriction are likely drivers. bshum, do you use either of those? |
| 15:31 |
eeevil |
kmlussier: not ... exactly |
| 15:31 |
eeevil |
kmlussier: but, parts of "restrictive rule" will contribute to potentially exposing the issue |
| 15:31 |
bshum |
eeevil: No to age protection, and as for transit distance, sort of, but I have to do some more investigation on what that's actually doing if anything. |
| 15:32 |
bshum |
eeevil: I think we have some rules set with transit distance true and a value of 2 or something in the matrix |
| 15:32 |
bshum |
For stuff that was intended to be local pickup only or something. |
| 15:32 |
bshum |
Not sure if those were written correctly, actually, now that I'm looking at it again. |
| 15:38 |
bshum |
eeevil: This isn't exactly apples, but I did a hold permit test on our old production DB hardware (pre-mvf upgrade scripts, etc.) vs. live and it was something like 12-18 ms vs. 400-800 ms |
| 15:38 |
bshum |
When I ripped out the rec_descriptor bits in live, that went down to like 24 ms or so |
| 15:38 |
bshum |
So I'm not sure transit range hurt me as much as that did |
| 15:39 |
eeevil |
bshum: well, it's not that |
| 15:39 |
eeevil |
I'm not saying that the problem isn't mrd |
| 15:40 |
eeevil |
what I'm saying is that it only really matters when you have a very long list of holds to test for |
| 15:40 |
eeevil |
and none of them pass |
| 15:40 |
eeevil |
if the first one passes, we look no further and capture |
| 15:40 |
eeevil |
but if we have to roll through all 100, then the difference matters |
| 15:41 |
eeevil |
so, if we create a mat-view for mrd, this will likely not be an issue |
| 15:41 |
eeevil |
in the case I just described |
| 15:41 |
eeevil |
but my point is that 99.9% of the time, you're not in that situation where there are 100+ unfillable holds |
| 15:42 |
eeevil |
which, again, is not to say that we shouldn't fix this ... we have several options |
| 15:42 |
eeevil |
but just to say that we're not seeing across-the-board 2.6 fail because most of the time it doesn't matter |
| 15:43 |
eeevil |
transit range is what can cause all 100+ holds to fail for a given (distant) copy. that's a trigger that can expose a given staff user to this behavior |
| 15:44 |
eeevil |
but transit range isn't the cause ... does that make sense? |
| 15:44 |
kmlussier |
eeevil: I think that 99.9% number is highly dependent on the Evergreen site. You're probably right when it comes to the networks I work with, but aren't there a fair number of Evergreen sites that rely more heavily on transit distance rules? |
| 15:46 |
eeevil |
kmlussier: the transit distance restriction is just how the door opens. it doesn't mean that they will suffer from this |
| 15:46 |
eeevil |
they still need tons of /distant/ holds that are at the front of the "queue" (hold sort order) |
| 15:48 |
eeevil |
kmlussier: if they sort local holds first, and there are any local holds (which, for a hot item is likely) then they're safe. and most sites use boundaries, not transit distance, for the "don't send it far away" case |
| 15:48 |
pastebot |
"dbwells" at 64.57.241.14 pasted "rec_descriptor as wide select" (18 lines) at http://paste.evergreen-ils.org/65 |
| 15:48 |
eeevil |
boundaries close the door to this issue in the common case |
| 15:48 |
eeevil |
well, in all but the most artificially-constructed worst case |
| 15:49 |
eeevil |
dbwells: indeed, just so |
| 15:49 |
dbwells |
bshum: eeevil: I am getting better plans using the view in the paste above (as described by eeevil). |
| 15:50 |
eeevil |
bshum: if that view replacement doesn't go far enough, a mat-view based on that is the next step, and that's as fast as mrd can get (faster than since 1.0, when it was a table) |
| 15:50 |
dbwells |
I was testing with dkyle's original query, since it was a handy case for testing, so I'll be interested to see if it also helps bshum's holds case. |
| 15:55 |
* bshum |
live tests, because hey, that's just how we roll now |
| 15:55 |
kmlussier |
bshum++ |
| 15:55 |
kmlussier |
bshum: Better you than me. :) |
| 16:04 |
hbrennan |
bshum: It's more exciting that way |
| 16:04 |
bshum |
hbrennan: Oh, so what happened? |
| 16:05 |
jeff |
quaqua/cl |
| 16:05 |
* jeff |
cocks his head |
| 16:05 |
jeff |
ah. |
| 16:06 |
hbrennan |
bshum: Well, turns out that we had a copy LOCATION that was unnamed/blank, so when we went in and messed with the circ policies, it awoke a previous problem |
| 16:07 |
hbrennan |
so then the circ policies were looking for things that were blank |
| 16:07 |
hbrennan |
and it freaked out |
| 16:07 |
hbrennan |
so we really did do everything right |
| 16:07 |
gsams |
hbrennan: I actually just had that happen to me |
| 16:07 |
gsams |
and was going to suggest that was the case |
| 16:08 |
gsams |
someone created a blank shelving location at top level and it auto applied it |
| 16:08 |
hbrennan |
yep! |
| 16:08 |
hbrennan |
Turns out it was for things that were On Order |
| 16:08 |
hbrennan |
currently I have it named Other so that it would stop breaking things |
| 16:08 |
hbrennan |
so completely unrelated to what we were doing/poking |
| 16:09 |
gsams |
I'm glad that was resolved at least! |
| 16:09 |
gsams |
In my case, it was a location that was created by accident, so I was able to just delete it. |
| 16:10 |
hbrennan |
on the circ desk... sorry |
| 16:12 |
hbrennan |
and today I came in really early, Equinox and I got it figured out |
| 16:12 |
hbrennan |
and then, while we were open again.. hehe... I tried out creating circ policies and circ limit sets! |
| 16:12 |
hbrennan |
and I didn't break anything! |
| 16:12 |
gsams |
woo! |
| 16:13 |
hbrennan |
Since all checkout limits were previously being regulated by the penalties we removed, I had to create some new limit sets and circ policies for our different groups |
| 16:13 |
bshum |
dbwells: eeevil: Only a preliminary test, but I applied that new paste for the rec_descriptor and asked jventuro to run a test report using a fixed field data element. It ran successfully. |
| 16:13 |
hbrennan |
First time since Equinox set up our policies that anyone has touched them... I didn't even have permission to view them yesterday |
| 16:14 |
bshum |
She's going to test another one (the report that we know broke for sure) while I did back out the original find_hold_matrix_matchpoint function to retest my case. |
| 16:14 |
hbrennan |
so equinox++ too |
| 16:14 |
hbrennan |
since they were humored more than anything by our situation this morning |
| 16:15 |
gsams |
hbrennan: that was more or less what I was with mine. It wasn't the first time I had seen it myself anyway, I have bshum to thank for that one though. |
| 16:16 |
gsams |
I think that moment was what made me want to utilize the database more |
| 16:18 |
hbrennan |
Yep, some of those screens aren't very user friendly |
| 16:18 |
hbrennan |
and I never could seem to sort them the way I wanted |
| 16:18 |
bshum |
Well, at least the filtering is better with newer versions. Some of them anyways. |
| 16:19 |
bshum |
Imagine paging 15 at a click through circ/hold rules without filtering when you have thousands of rules :D |
| 16:19 |
hbrennan |
true |
| 16:19 |
bshum |
That is my life. |
| 16:20 |
hbrennan |
I I struggled with printing a page of the policies, because it was cutting off #15 on the list |
| 16:20 |
hbrennan |
so I had to screenshot it |
| 16:21 |
kmlussier |
But there is filtering on those screens now. Makes them much easier to use. |
| 16:23 |
bshum |
dbwells: eeevil: Yes, the permit hold test is faster now with the new rec_descriptor view in place. Or at least not above 50 ms, so reasonable. |
| 16:23 |
eeevil |
cool ... simple CREATE OR REPLACE VIEW upgrade script, then |
| 16:23 |
eeevil |
dbwells++ |
| 16:23 |
eeevil |
bshum++ |
| 16:24 |
hbrennan |
kmlussier: In my crazy morning, I didn't notice the Filter option on Circ policies.. That would have been great to narrow down to a particular group.. good to know now! |
| 16:25 |
hbrennan |
I think I still just look for a search box |
| 16:29 |
kmlussier |
hbrennan: The trick is knowing how to enter a search term if you aren't doing an exact match. Use the "is like" option and surround your search terms with % |
| 16:30 |
hbrennan |
kmlussier: Super tip, thanks! |
| 16:30 |
hbrennan |
kmlussier |
| 16:31 |
hbrennan |
kmlussier++ that is |
| 16:36 |
|
ericar joined #evergreen |
| 16:40 |
|
tspindler left #evergreen |
| 16:53 |
hbrennan |
Dang, just almost had to use our defibrillator! phew.. long day already |
| 16:53 |
gmcharlt |
oh dear |
| 16:54 |
hbrennan |
seizure in the parking lot |
| 16:54 |
|
bmills joined #evergreen |
| 16:54 |
|
dluch joined #evergreen |
| 17:05 |
kmlussier |
So this is weird. On the advanced search page, there is an x that allows you to remove a search row. I noticed a couple of weeks ago that I don't see those x's on anyone's catalog (I looked at several) using either Firefox or Chrome. |
| 17:05 |
kmlussier |
I just discovered that the AdBlock plugin for Firefox and Chrome blocks them. |
| 17:05 |
* gmcharlt |
blinks |
| 17:06 |
bshum |
Oh that's cool |
| 17:06 |
bshum |
And by "cool" I mean, wtf? |
| 17:06 |
gmcharlt |
I guess Sesame Street's campaign to promote the letter X is now foiled. Curses! |
| 17:07 |
kmlussier |
It's easy enough to stop the plugin from working on those pages, but, yeah. I wonder how many people are using the plugin and never realized they could remove a search row. |
| 17:07 |
kmlussier |
And would they suddenly start removing search rows if they knew they had that power? |
| 17:09 |
|
mmorgan left #evergreen |
| 17:11 |
gsams |
I'm seeing some odd behavior with some recently setup action/trigger courtesy notices |
| 17:11 |
gsams |
-1 days, they seem to be generating properly, but they email out the day the items are due |
| 17:12 |
gsams |
which is a bit less than helpful in our case |
| 17:12 |
gsams |
I'm not really sure where this would be going wrong though |
| 17:18 |
|
berick joined #evergreen |
| 17:19 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:47 |
|
hbrennan joined #evergreen |
| 19:16 |
|
hbrennan joined #evergreen |
| 21:02 |
|
GtownJoe joined #evergreen |
| 21:03 |
GtownJoe |
@list |
| 21:03 |
pinesol_green |
GtownJoe: Admin, Anagram, Assorted2, Blame, Bugtracker, Channel, ChannelLogger, Config, Dessert, Dunno, Encyclopedia, Games, Git, Herald, Insult, Karma, Later, LoveHate, MARC, Math, MeetBot, Misc, Note, Owner, Praise, Quote, RSS, Reply, Seen, Status, Time, Todo, Twitter, User, and Weather |
| 21:06 |
|
GtownJoe left #evergreen |
| 22:01 |
|
mllewellyn joined #evergreen |
| 22:02 |
|
mmorgan1 joined #evergreen |
