Evergreen ILS Website

IRC log for #evergreen, 2016-02-08

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

All times shown according to the server's local time.

Time Nick Message
05:03 lualaba joined #evergreen
05:03 lualaba Hello anyone know how to fix this issue? https://bugs.launchpad.net/evergreen/+bug/1491875
05:03 pinesol_green Launchpad bug 1491875 in Evergreen "Erroneous "Tab may have unsaved data" message when creating new MARC record" [Undecided,New]
06:15 lualaba joined #evergreen
07:33 rjackson_isl joined #evergreen
07:40 Stompro joined #evergreen
07:54 ericar joined #evergreen
07:57 JBoyer joined #evergreen
08:28 mrpeters joined #evergreen
08:43 mmorgan joined #evergreen
08:43 mdriscoll joined #evergreen
08:48 mmorgan joined #evergreen
08:50 tspindler joined #evergreen
09:29 maryj joined #evergreen
09:35 jvwoolf joined #evergreen
09:50 RoganH joined #evergreen
09:50 collum joined #evergreen
09:59 mrpeters left #evergreen
10:00 mmorgan1 joined #evergreen
10:28 mceraso We would like to post a job to https://evergreen-ils.org/jobs/
10:28 mceraso Is there a specific person that is responsible for maintaining this page?
10:28 mceraso Any help would be appreciated :)
10:29 RoganH mceraso: that would be me
10:29 mceraso RoganH: Excellent!
10:29 mceraso Would it be best to email you the posting?
10:29 RoganH mceraso: that will work, I'll have it up today
10:30 mceraso Fantastic! I can send it right now
10:34 Bmagic RoganH: Have you played Ecplise?
10:34 RoganH Bmagic: not yet
10:34 Bmagic hopkinsju thought we should bring it to the converence
10:35 RoganH I say do it.  I've heard it's good but hadn't played it yet.
10:36 Bmagic The main concern I have is it's a serious game. Players need to commit
10:36 RoganH It's a driving trip for me so I'll bring a few things since I can throw them in the car.  I'll play.
10:36 Bmagic im sure I can find somewhere in my luggage to stow it (I will probably take the pieces in zip locks instead of the large box)
10:38 Bmagic I'm thinking eclipse, hanabi (of course), splindor, set, the resistance
10:39 RoganH Hanabi is good, splendor is good (only played it a few times but liked it), resistance is fun but beer helps :)
10:40 Bmagic do you have a copy of any of those?
10:40 RoganH I have splendor and resistance
10:41 Bmagic we should have the board games covered then
10:41 Bmagic :)
10:42 RoganH :)
10:43 rlefaive joined #evergreen
11:16 afterl joined #evergreen
11:20 dbwells joined #evergreen
11:21 mmorgan joined #evergreen
11:39 sandbergja joined #evergreen
11:48 tspindler @weather 01606
11:48 pinesol_green tspindler: Worcester, MA :: Snow :: 15F/-9C | Wind Chill: -2F/-19C | Monday: Cloudy with snow. High 22F. Winds N at 15 to 25 mph. Chance of snow 90%. Snow accumulating 3 to 5 inches. Winds could occasionally gust over 40 mph. Monday Night: Snow this evening will taper off and give way to cloudy skies late. Low 16F. Winds NNE at 10 to 20 mph. Chance of snow 80%. About one inch (1 more message)
11:54 kmlussier @weather
11:54 pinesol_green kmlussier: Seekonk, MA :: Snow :: 20F/-7C | Wind Chill: 3F/-16C | Monday: Snow along with gusty winds at times. High near 25F. Winds N at 20 to 30 mph. Chance of snow 100%. Snow accumulating 3 to 5 inches. Winds could occasionally gust over 40 mph. Monday Night: Mainly cloudy with snow showers around this evening. Low 19F. Winds N at 15 to 25 mph. Chance of snow 50%. Snow (1 more message)
11:54 kmlussier @more
11:54 pinesol_green kmlussier: accumulations less than one inch.
12:08 Christineb joined #evergreen
12:30 tspindler left #evergreen
12:33 mmorgan left #evergreen
12:37 mdriscoll left #evergreen
13:07 lualaba_ joined #evergreen
13:26 mceraso RoganH++ #thank you!
13:26 RoganH mceraso: glad to!
13:29 abneiman joined #evergreen
13:35 kmlussier @quote random
13:35 pinesol_green kmlussier: Quote #128: "<gmcharlt> for a moment I had fears that Google Telepathy had exited alpha" (added by csharp at 09:15 AM, November 09, 2015)
13:36 RoganH If they're using it to power ads they need to work on the algorithm because it's not giving me ads for what I'm thinking about.
14:56 Stompro Can someone give me a pointer on how to set our system to include the 245 subfield n in the title for super_simple_extract info, and hopefully the title field in pull lists?
15:05 dbs Stompro: hmm, I think that would involve customizing the reporter.simple_record view
15:05 dbs which (at least in our 2.7-ish instance) defines title as "LEFT JOIN metabib.full_rec title ON r.id = title.record AND title.tag = '245'::bpchar AND title.subfield = 'a'::text"
15:06 dbs and once you work that out, you would need to then refresh the metabib.materialized_simple_record table
15:10 Stompro dbs, Thanks for the info.
15:10 dbs Stompro: I think that's right, anyway - you probably want to try on a test server first :)
15:13 JBoyer To zoom out even further, you'll want to look (in the IDL) at what your reporter is using: reporter.simple_record or repoter.super_simple_record. I haven't looked at what's used where yet, but rssr uses a materialized view built from a trigger on biblio.record_entry, while rsr is using a large multi-join view instead.
15:16 JBoyer Ok, they're both views, but rssr is just a simple select against reporter.materialized_simple_record.
15:16 dbs JBoyer: which is in turn built from rsr
15:18 dbs orrrrrr
15:18 dbs our reporter.simple_rec_update trigger says "INSERT INTO reporter.materialized_simple_record SELECT DISTINCT ON (id) * FROM reporter.old_super_simple_record WHERE id = r_id;"
15:18 dbs rossr!
15:20 JBoyer Ugh, you're right. I saw INSERT INTO and then stopped paying attention. rossr it is, and another view.
15:21 dbs in which case I guess rossr is the one to modify, but then if it's old why are we still using it? weird :)
15:21 JBoyer I do have something to add re: that though, I had a hell of a time selecting for 2 subfields and forcing them to be ordered consistently. I may have been doing something wrong, but what I ended up with is somewhere in the CollectionHQ changes I made.
15:21 JBoyer dbs: it's harder to refactor tables than code, would be my guess. :)
15:21 dbs Yeah, I was thinking about that and you would probably need to do another LEFT JOIN metabib.full_rec title ON r.id = title.record AND title.tag = '245'::bpchar AND title.subfield =  'a'::text"
15:21 dbs except s/title/title_n/ and s/'a'/'n'/
15:23 dbs and then change the SELECT first(title.value) AS title to something like (first(title.value) || first(title_n.value)) AS title
15:23 dbs spitballin
15:24 JBoyer That's probably better than what I came up with way back when, I believe it involved WITH.
15:24 JBoyer and an ordered subselect, etc.
15:25 afterl joined #evergreen
15:26 dbs I like WITH too :)
15:27 Stompro Thanks, JBoyer++ & dbs++  I'll take a look at that.  I might post to the list about it also, We have a bunch of dvd series where the 245n is the only unique part of the title, so finding them with the simple pull list is something staff have complained about.
15:28 JBoyer dbs: more fun down that rabbit hole: metabib.full_rec is a view on metabib.real_full_rec that just cuts the value at 1024 chars. Depending on how you follow things from reporter.something_or_other you're 3-4 views deep.
15:33 * jeff scrolls up
15:34 jeff ah.
16:00 jlitrell joined #evergreen
16:02 dbs JBoyer: yep, mfr needs to cut the value at 1024 chars because full-text search indices default to a max of 1024 chars and complain bitterly if they hit a field with a value longer than that (hi 50x fields)
16:02 rlefaive joined #evergreen
16:03 JBoyer Ah.
16:03 dbs it might have even been laurentian data that pushed miker to having to create the mfr view...
16:05 JBoyer That rings a bell. I ran across an "enhanced" 505 that had every single sub-title in a single $t. When I added 505 $t to our title indexes that was not appreciated. :)
16:06 miker dbs: it might have been, indeed. the limit is more like 1700 bytes, (or, ~3 tuples per page) but with chars != bytes, etc, 1k seemed a reasonable limit. you can (and we have, in the past) worked around that by increasing the page size ... but that's no fun
16:07 miker I think it may have been a direct btree index on mfr.value that was the problem ... with GIN, fts should be fine on larger strings. certainly it is in metabib.keyword_field_entry
16:08 jeff i think we only have a few titles > 1024 ;-)
16:08 jeff oh, nope! not anymore, at least.
16:09 jeff all 5xx tags, then a single 740$a and a single... 004. hah!
16:09 jeff I am also amused at the two 505$! (subfield '!') values > 1024.
16:10 dbs hah
16:10 JBoyer Well, if any subfield needs to be > 1024, ! would be it. :D
16:13 jeff the long 004 is just a malformed record (possibly someone pasted something where it didn't belong either on our end or a vendor's end). the long 740 is... Aesop's Fables.
16:14 jeff also... yeah, an 004.
16:18 jeff all five subfields '!' are on a single record.
16:26 abneiman joined #evergreen
17:32 rlefaive joined #evergreen
17:43 dcook joined #evergreen
18:32 rlefaive joined #evergreen

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