| Time |
Nick |
Message |
| 07:27 |
kmlussier |
Happy Vernal Equinox #evergreen! |
| 07:27 |
kmlussier |
@weather 02771 |
| 07:27 |
pinesol_green |
kmlussier: The current temperature in Rumford, East Providence, Rhode Island is 18.1°F (7:25 AM EDT on March 20, 2015). Conditions: Mostly Cloudy. Humidity: 81%. Dew Point: 14.0°F. Windchill: 17.6°F. Pressure: 30.38 in 1029 hPa (Steady). |
| 07:28 |
kmlussier |
Sigh... |
| 07:47 |
|
jboyer-isl joined #evergreen |
| 07:56 |
|
collum joined #evergreen |
| 07:57 |
|
graced joined #evergreen |
| 07:58 |
|
rjackson_isl joined #evergreen |
| 08:21 |
csharp |
sudo apt-get update && sudo apt-get install openssl |
| 08:22 |
* csharp |
can't keep track of how often he's had to run that over the last year |
| 08:24 |
|
Shae joined #evergreen |
| 08:28 |
csharp |
@weather 30341 |
| 08:28 |
pinesol_green |
csharp: The current temperature in Rose Arbor, Atlanta, Georgia is 45.9°F (8:25 AM EDT on March 20, 2015). Conditions: Overcast. Humidity: 99%. Dew Point: 46.4°F. Windchill: 46.4°F. Pressure: 30.13 in 1020 hPa (Falling). |
| 08:29 |
csharp |
Rose Arbor? - never heard of that name, but it may be another of Metro Atlanta's proposed Balkanized states |
| 08:43 |
|
mrpeters joined #evergreen |
| 08:45 |
csharp |
@later tell Dyrcona we had talked a while back about marc_export letting us know the bib ID for the too-large invalid MARC records it creates (see bug 1397532) - is that something you think could be added without a lot of trouble? OCLC is now unwilling to work around them on their end. |
| 08:45 |
pinesol_green |
csharp: The operation succeeded. |
| 08:55 |
|
Dyrcona joined #evergreen |
| 08:58 |
|
maryj joined #evergreen |
| 09:00 |
|
ericar joined #evergreen |
| 09:18 |
|
Stompro joined #evergreen |
| 09:20 |
|
mmorgan joined #evergreen |
| 09:44 |
bshum |
csharp: openssl or libssl1.0.0? |
| 09:44 |
bshum |
Or both? :) |
| 09:46 |
Dyrcona |
A little birdy tells me I have a later. |
| 09:47 |
Dyrcona |
bshum: libssl is OpenSSL, unless you're using LibreSSL, which you most likely are not. |
| 09:47 |
Dyrcona |
And, LibreSSL is affected by some of the same CVEs. |
| 09:48 |
Dyrcona |
Hope I guessed the topic of conversation without context correctly. |
| 09:48 |
Dyrcona |
:) |
| 09:48 |
bshum |
Right :) |
| 09:56 |
|
jeff_ joined #evergreen |
| 09:56 |
Dyrcona |
csharp: On your marc export later, I thought we took care of that at one point, but I can't find a launch pad bug about it. |
| 09:58 |
Dyrcona |
Oh, wait, you're talking about the ones that are too large. |
| 09:58 |
Dyrcona |
That's not easy to fix, and might actually require changes to MARC::Record. |
| 09:58 |
Dyrcona |
Vendors should just a) accept MARCXML and b) ignore the size field. |
| 09:59 |
Dyrcona |
It's a throwback to the days of limited storage. |
| 09:59 |
Dyrcona |
With an end of record indicator in the binary format, it is also unnecessary. |
| 10:00 |
Dyrcona |
There's a lot of stupidity in the MARC format itself. |
| 10:00 |
jboyer-isl |
Dyrcona: it was designed for tape. If you know how long the record is you can skip ahead without looking for the EOR marker. |
| 10:00 |
Dyrcona |
Another option is just don't send them holdings, but that's the whole point of sending to OCLC. |
| 10:01 |
Dyrcona |
jboyer-isl: I know what it was designed for and it serverd that purpose at that time OK. It totally sucks today. |
| 10:01 |
jboyer-isl |
You’ll certainly get no argument about that from me. |
| 10:01 |
jboyer-isl |
argument against that, rather. |
| 10:01 |
|
maryj joined #evergreen |
| 10:02 |
jeff |
heh. this ec2 instance has three attached block devices: root, "slow", and "notfast". |
| 10:02 |
Dyrcona |
heh. |
| 10:03 |
jeff |
only two errors on restore, and i believe those are the two index failures due to unqualified function names. |
| 10:03 |
jeff |
and transcript confirms! |
| 10:03 |
Dyrcona |
jeff: we might have qualified the function names in our db and not shared with the community. |
| 10:04 |
jeff |
possible. i'm going to confirm. |
| 10:04 |
Dyrcona |
I haven't run into that one for ages. |
| 10:10 |
Dyrcona |
jboyer-isl: And tape is limited storage...Only slightly less limited than punch cards. ;) |
| 10:12 |
jboyer-isl |
Dyrcona: Sure, but the size field is there because it’s linear, not just because it’s limited. :) Also, because “9999 characters is enough for anyone.” and no one imagined at the time why you’d want your holdings in a record. |
| 10:13 |
|
akilsdonk joined #evergreen |
| 10:13 |
Dyrcona |
Linear is a limitation. |
| 10:14 |
Dyrcona |
True about the holdings. The original purpose was to send the tape and have cards printed for the card catalog. |
| 10:14 |
Dyrcona |
Everything else we've made the format do is tacked on. |
| 10:14 |
Dyrcona |
And, since we're not using linear storage, and it's 2015, vendors should just ignore the size field. |
| 10:15 |
Dyrcona |
Evergreen ignores it, as does anything that uses MARC::Record. |
| 10:15 |
Dyrcona |
"But this software has worked since 1985! Why should we change it?" |
| 10:36 |
|
dreuther joined #evergreen |
| 10:45 |
collum |
http://www.cincinnati.com/story/news/2015/03/20/appeals-court-ky-library-tax-legal/25076117/ |
| 10:46 |
collum |
Yay!! |
| 10:46 |
bshum |
Yay! |
| 11:13 |
|
vlewis joined #evergreen |
| 11:13 |
|
sal_ joined #evergreen |
| 11:26 |
csharp |
Dyrcona: thanks - I thought that was the case |
| 11:26 |
csharp |
collum: awesome! |
| 11:59 |
|
sandbergja joined #evergreen |
| 12:05 |
|
bmills joined #evergreen |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:53 |
|
bmills joined #evergreen |
| 13:01 |
|
bmills1 joined #evergreen |
| 13:17 |
|
mglass joined #evergreen |
| 14:32 |
|
makohund joined #evergreen |
| 15:10 |
|
akilsdonk joined #evergreen |
| 15:27 |
kmlussier |
@swill graced |
| 15:27 |
* pinesol_green |
grabs a bottle of Zima and sends it sliding down the bar to graced |
| 15:38 |
csharp |
bshum: @seen StephenGWills |
| 15:38 |
csharp |
@seen StephenGWills |
| 15:38 |
pinesol_green |
csharp: StephenGWills was last seen in #evergreen 21 weeks, 4 days, 7 hours, 21 minutes, and 46 seconds ago: <StephenGWills> git branch, git merge maybe? |
| 15:39 |
csharp |
bshum: bleh - sorry :-/ |
| 15:39 |
csharp |
@swill StephenGWills |
| 15:39 |
* pinesol_green |
grabs a forty of Steel Reserve 211 and sends it sliding down the bar to StephenGWills |
| 15:39 |
csharp |
too bad he's not here - I have a feeling he would've chuckled at that :-) |
| 15:40 |
* kmlussier |
will chuckle on StephenGWills behalf. |
| 15:40 |
* jeffdavis |
googles Zima, shudders |
| 15:41 |
csharp |
his original nick was swills, so *that* would've been REALLY funny |
| 15:41 |
* csharp |
is in the office on his normal telework day, finally done with back-to-back-to-back meetings and feeling punchy |
| 15:43 |
kmlussier |
jeffdavis: That was my reaction as well. |
| 15:43 |
jeffdavis |
:) |
| 15:44 |
berick |
jeffdavis: you've never experienced Zima? |
| 15:44 |
berick |
you either, kmlussier? |
| 15:44 |
kmlussier |
berick: Is it as terrible as it sounds? |
| 15:44 |
sal_ |
... pokes head up. kmlussier: it's awful |
| 15:45 |
kmlussier |
sal_! Good to see you! |
| 15:45 |
berick |
it's awful, but was briefly the underage^H^H^Himature drinkers go-to. (not sure why, probably marketing) |
| 15:46 |
sal_ |
I'm playing with 2.7... (Finally, time to play again :-) ) |
| 15:46 |
* csharp |
remembers tasting zima in his college days |
| 15:46 |
kmlussier |
Based on my reading on Wikipedia, I wasn't underage when it came out. |
| 15:46 |
* kmlussier |
feels old now. |
| 15:47 |
berick |
@swill kmlussier |
| 15:47 |
* pinesol_green |
grabs a can of Sparks and sends it sliding down the bar to kmlussier |
| 15:47 |
kmlussier |
Can we get Sam Adams into the swill database? |
| 15:47 |
csharp |
@beer berick |
| 15:47 |
pinesol_green |
csharp: Have you tried turning it off and back on again? |
| 15:47 |
csharp |
@bartender berick |
| 15:47 |
* pinesol_green |
fills a pint glass with Hitachino Nest White Ale, and sends it sliding down the bar to berick (http://beeradvocate.com/beer/profile/697/2013/) |
| 15:47 |
* berick |
reads |
| 15:48 |
sal_ |
cider? (more beer for the rest of you...) |
| 15:48 |
csharp |
@swill add Sam Adams |
| 15:48 |
* pinesol_green |
grabs a can of Sparks and sends it sliding down the bar to add Sam Adams |
| 15:48 |
csharp |
heh |
| 15:48 |
makohund |
Tricerahops, maybe? |
| 15:48 |
berick |
wow, highly rated |
| 15:48 |
kmlussier |
Ha ha |
| 15:50 |
makohund |
Ruination? |
| 15:51 |
makohund |
I dunno, I just looked up and saw beer talk. Ya'll speaking my language all of a sudden. |
| 15:51 |
kmlussier |
makohund++ |
| 15:51 |
kmlussier |
I think beer is a good entry point for the #evergreen channel. :) |
| 15:52 |
makohund |
La Fin Du Monde? Just throwing out some favorites. :) |
| 15:53 |
makohund |
Been here before, not often though. Usually with a bizarre question, long after most folks seem gone for the day. |
| 15:54 |
* berick |
is suddenly thirsty |
| 15:54 |
rjackson_isl |
dirty bastard scotch ale! |
| 15:55 |
kmlussier |
I think we need one specifically for wine. Maybe we can adapt the dessert plugin to handle wine. |
| 15:56 |
makohund |
Sleigh'r! (Yes, a seasonal) |
| 15:59 |
* phasefx |
still likes New Belgian beers, and Monday Night Brewing :) |
| 15:59 |
berick |
@dunno add did you finish your beer? |
| 15:59 |
pinesol_green |
berick: The operation succeeded. Dunno #37 added. |
| 16:06 |
kmlussier |
@dunno |
| 16:06 |
pinesol_green |
kmlussier: It reads like a Nigerian 419 scam, but I think it is a sincere question sent to the wrong list. |
| 16:06 |
* berick |
chuckles |
| 16:07 |
berick |
kmlussier: if you use an invalid command, it will reply w/ a @dunno entry |
| 16:07 |
berick |
@foo |
| 16:07 |
pinesol_green |
berick: Yeah, well, you know, that's just like uh, your opinion, man. |
| 16:08 |
makohund |
that just makes me thirstier |
| 16:10 |
berick |
heh |
| 16:11 |
berick |
@quote random |
| 16:11 |
pinesol_green |
berick: Quote #69: "jeff: All the pain of RHEL, with none of the support." (added by Dyrcona at 08:57 AM, October 30, 2013) |
| 16:14 |
jeff |
hah |
| 16:26 |
makohund |
Ok, real question... I need to report on a bunch of items (status = 3), grouped by user profile of most recent checkout. In other words... "how many items have been lost by this category of patrons". Any ideas? |
| 16:27 |
jeff |
lots of ways to skin that cat. for one thing, you can report on open circulations with a stop_fines of LOST. |
| 16:27 |
jeff |
first question is probably going to be: SQL or Reporter? |
| 16:29 |
makohund |
Nevermind the report module, psql is fine. I was looking for a non-ridiculous join between asset.copy and actor.usr... I could swear I saw a field in a table somewhere that looked like what the "most recent checkout" screen pulled from. |
| 16:30 |
makohund |
Just can't remember what it was... and yeah, lots of ways to skin that one. Just picking which angle to start from is... yeah. |
| 16:30 |
dbs |
makohund: join action.circulation to actor.usr and asset.copy (IIRC) |
| 16:33 |
dbs |
SELECT * FROM action.circulation ac INNER JOIN actor.usr au ON au.id = ac.usr INNER JOIN asset.copy acp ON acp.id = ac.target_copy WHERE stop_fines = 'LOST'; -- is a start, then narrow down your columns and add your GROUP BY / COUNT accordingly |
| 16:33 |
makohund |
dbs: thanks, I know I could ultimately get there that way, was hoping to find a shortcut somewhere that wouldn't have to look at every transaction of all time... oh wait, lemme read that... |
| 16:34 |
dbs |
SELECT pgt.name, COUNT(*) FROM action.circulation ac INNER JOIN actor.usr au ON au.id = ac.usr INNER JOIN asset.copy acp ON acp.id = ac.target_copy INNER JOIN permission.grp_tree pgt ON pgt.id = au.profile WHERE stop_fines = 'LOST' GROUP BY pgt.name; |
| 16:34 |
dbs |
will probably do what you want |
| 16:35 |
jeff |
there is no materialized view that includes "most recent circ of this item", so either way you're going to be relying on the planner and indexes to keep you from touching every transaction of all time. |
| 16:35 |
dbs |
oh, or change the "stop_fines = 'LOST'" to "acp.status = 3" |
| 16:35 |
makohund |
dbs: ok, limit to stop_fines = lost makes me feel a little better, thanks |
| 16:35 |
dbs |
It shouldn't be too horrible, the default indexes should guide things pretty well |
| 16:36 |
jeff |
wow. we have only one copy with status of Lost that isn't associated with an open circ. that's... I almost don't believe that. :P |
| 16:36 |
makohund |
dbs: I was thinking of keeping both |
| 16:37 |
makohund |
I'll grab that & translate into what I have already, and post back, thanks! |
| 16:37 |
dbs |
Running against our database, I get wildly different numbers for stop_fines = "LOST" vs. status = 3. Probably because we migrated lots of copies from the old system with a status of LOST |
| 16:37 |
dbs |
SQL makes me happy. |
| 16:37 |
makohund |
me too, the reporter immediately scared me away |
| 16:38 |
makohund |
simply couldn't do what we needed without adding custom sources |
| 16:41 |
|
mrpeters left #evergreen |
| 16:57 |
jeff |
here's another option: https://gist.github.com/jeff/252fa162d30265abe92a |
| 16:58 |
jeff |
tricks like "group by second level profile" left as an exercise to the reader |
| 17:09 |
makohund |
thanks, will look at those when I get a moment, my head has been buried in SIP logs on my other monitor... ugh. |
| 17:15 |
* jeff |
updates said gist a few times |
| 17:15 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:15 |
jeff |
dbs++ for the recursive CTE trick |
| 17:16 |
jeff |
for what it's worth, those queries are pretty speedy on an underpowered dev instance |
| 17:16 |
makohund |
oooh... very nice. so open circ view... does that mean any circ that gets closed out by marking as lost/missing/etc will forever remain an "open circ", and will be in there? |
| 17:17 |
jeff |
action.open_circulation is a view based on action.circulation where checkin_time is NULL |
| 17:17 |
jeff |
"lost" items never get checked in (unless they find their way home, etc) |
| 17:17 |
makohund |
Ah. Got it. |
| 17:17 |
jeff |
(in which case the copy's status usually ALSO stops being "Lost" or "Lost and Paid") |
| 17:18 |
makohund |
Yeah, makes sense. |
| 17:18 |
jeff |
if you didn't already know, "\d+ action.open_circulation" in the psql shell will show you the definition of a view, including the SQL query behind it |
| 17:18 |
jeff |
WHERE acp.circ_lib IN (SELECT id FROM actor.org_unit_descendants(1)) -- option to limit by copy circ lib |
| 17:19 |
jeff |
that line lets you plug in an org unit id if you want to limit to a specific part of the org hierarchy. |
| 17:21 |
makohund |
Yeah, one of those things lurking in a dusty mind closet, long unused. And yeah, saw that line. Slick. |
| 17:23 |
jeff |
previous to that, we used to do things like acp.circ_lib BETWEEN 3 AND 5 or acp.circ_lib IN (3,4,5), but that breaks very quickly when you've added a library, etc. |
| 17:25 |
makohund |
Yep. I get away with that (usually IN()), the org tree is pretty simple here. Only one system (mine) here has more than one branch. |
| 17:52 |
jeff |
i do wonder about the 280 items that are "Checked out" with stop_fines of LOST. |
| 17:52 |
jeff |
@blame migrated data |
| 17:52 |
pinesol_green |
jeff: migrated data broke Evergreen. |
| 17:58 |
|
bmills joined #evergreen |
| 18:15 |
|
bmills joined #evergreen |
| 18:30 |
|
bbqben joined #evergreen |
| 18:33 |
|
bbqben joined #evergreen |
| 18:36 |
makohund |
just tried the query from dbs, also got wildly different numbers from stop_fines vs status. For one profile, it is 11,151 vs 68,611. |
| 18:37 |
makohund |
For another, the main one we want to look at (that didn't even exist pre-migration), it is 75 vs 479. Wow... going to look at those closer to see where the diff is. |
| 18:49 |
makohund |
found an item that shows up with status, but not with stop_fines. status is 3, status change time is well after migration (over a year). stop_fines is CHECKIN. hmm. |
| 19:03 |
makohund |
ok, looks like the second query hits things multiple times. it's lost now, but it checked out 33 times. so just limiting it by that gets all 33 transactions |
| 19:19 |
|
bbqben joined #evergreen |
| 19:20 |
makohund |
OK, jeff's query gets 38 for that same profile, instead of 75. poked around, the difference is using open_circulation vs circulation. |
| 19:36 |
makohund |
just action.circulation is getting lots of things that were eventually checked in, and no longer have a status of lost. if using both stop_fines and status, the result is the same. Yay! |
| 19:36 |
jeff |
heh |
| 19:38 |
jeff |
so is the query i shared suitable, or did it require some modification? |
| 19:44 |
makohund |
It's good. I stripped it down & changed some names to how I usually do it in the process, but running mine & yours back to back gets the same numbers. Almost* |
| 19:45 |
makohund |
Exactly one profile turns up exactly one additional lost item, when I run my version. *boggle* |
| 21:05 |
makohund |
gotta split, thanks! |
| 21:05 |
|
makohund left #evergreen |
