| 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 |
