| Time |
Nick |
Message |
| 06:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 07:06 |
|
rjackson_isl joined #evergreen |
| 07:06 |
|
JBoyer joined #evergreen |
| 07:31 |
|
agoben joined #evergreen |
| 07:52 |
|
rlefaive joined #evergreen |
| 08:07 |
|
JBoyer joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:56 |
|
Dyrcona joined #evergreen |
| 09:00 |
|
bos20k joined #evergreen |
| 09:22 |
|
terran joined #evergreen |
| 09:29 |
|
jvwoolf joined #evergreen |
| 09:37 |
|
yboston joined #evergreen |
| 09:39 |
|
rlefaive joined #evergreen |
| 09:40 |
|
dbwells joined #evergreen |
| 09:43 |
Dyrcona |
irc_logs++ |
| 10:03 |
|
mmorgan1 joined #evergreen |
| 10:14 |
|
kmlussier joined #evergreen |
| 10:41 |
|
wsmoak joined #evergreen |
| 10:41 |
|
troy__ joined #evergreen |
| 10:42 |
pinesol_green |
[evergreen|Jason Boyer] LP1744489: Location Search Limiter - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df6e607> |
| 10:51 |
|
mmorgan joined #evergreen |
| 11:24 |
|
khuckins joined #evergreen |
| 11:26 |
|
rlefaive joined #evergreen |
| 11:37 |
|
Christineb joined #evergreen |
| 11:53 |
berick |
rhamby++ # going to have a busy conference |
| 11:53 |
rhamby |
berick: yeeeeeeeeppppp..... |
| 12:04 |
bshum |
Ooooo pretty colors |
| 12:04 |
|
khuckins_ joined #evergreen |
| 12:06 |
|
khuckins_ joined #evergreen |
| 12:15 |
|
jihpringle joined #evergreen |
| 13:17 |
kmlussier |
hmmm...so the email that the feedback evergreen-ils.org address just received sounds very similar to the EDI issue Dyrcona was talking about last week. |
| 13:18 |
Dyrcona |
B&T not accepting Enriched EDI? |
| 13:19 |
kmlussier |
Dyrcona: yup |
| 13:19 |
kmlussier |
rhamby++ # Responding to the email. |
| 13:20 |
Dyrcona |
We basically told B&T to lump it. They ignore it for the book orders, so they should be able to figure out how to ignore it for A/V orders as well. :) |
| 13:34 |
JBoyer |
SO! Speaking of B&T and EDI, anyone using the new edi_order_pusher.pl for B&T ordering? I've only just now gotten it to work (active/passive FTP hassles) but it's not putting the library SAN in the message anywhere. This is obviously sub-optimal. |
| 13:35 |
JBoyer |
And I wanted to see if there's just an EDI Settings flag to flip or if it's time to learn a lot of supr::UGLI:::codez. |
| 13:36 |
Dyrcona |
Not using it, yet, but your ideas interest me. Please, sign me up for your newsletter. :) |
| 13:40 |
* csharp |
conjures the soul of berick for an answer |
| 13:40 |
* csharp |
remembers something about library SANs and new EDI |
| 13:40 |
csharp |
that's still on our to-implement list |
| 13:41 |
JBoyer |
B&T has a weird flag where their code is combined with yours in some field, I haven't changed the defaults but having never sent a successful message before today I don't have a lot to compare to. |
| 13:42 |
JBoyer |
(And I try not to go straight to berick all of the time because I don't know who's actually ordering from who, thought I guess B&T probably does have a pretty high % of the available market) |
| 13:43 |
* JBoyer |
is also in the middle of testing 1-2 patches and should try to finish something before starting more things... |
| 13:44 |
|
bos20k joined #evergreen |
| 13:51 |
csharp |
JBoyer++ # I'm right there with you on the multitasking thing |
| 13:52 |
|
mmorgan1 joined #evergreen |
| 13:57 |
* csharp |
breaks down and adds the queries from bug 1738488 to the query-killing cron job he runs for long-running bib searches |
| 13:57 |
pinesol_green |
Launchpad bug 1738488 in Evergreen 3.0 "Web client: patron billing history results in long running query" [Medium,Confirmed] https://launchpad.net/bugs/1738488 |
| 13:58 |
berick |
JBoyer: had a conversation w/ Bmagic about this recently. |
| 13:58 |
berick |
i think there's an LP |
| 13:58 |
JBoyer |
Aha. Will seek that out. |
| 13:58 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1739465 |
| 13:58 |
pinesol_green |
Launchpad bug 1739465 in Evergreen "New EDIWriter.pm is using the wrong SAN for NAD+BY" [Undecided,Confirmed] |
| 14:00 |
JBoyer |
I remember thinking that line looked odd but at that point it wouldn't send anything anywhere. Excellent. |
| 14:00 |
JBoyer |
berick++ |
| 14:08 |
|
collum joined #evergreen |
| 14:16 |
JBoyer |
berick, to make sure I'm following correctly, the vendacct field isn't used when the vendcode field is? (i.e. buyer_code can only ever be one of these constructs: acqedi.vendcode only, aou.san + acqedi.vendcode, or acqedi.vendcode only.) B&T has been sending some screenshots that look like they may expect acqedi.vendacct + acqedi.vendcode |
| 14:18 |
JBoyer |
That's similar to what you'll get from aou.mailing_addr.san + acqedi.vendcode, so long as aou... == acqedi... but I didn't know if there was some benefit to being able to being able to use more than one SAN per OU. |
| 14:21 |
* berick |
looks |
| 14:23 |
berick |
JBoyer: right. vendacct OR org_san + vendcode OR vendcode |
| 14:23 |
berick |
BT traditionally wants org_san + vendcode |
| 14:24 |
berick |
applying the patch above fixed Bmagic's BT problems, fwiw |
| 14:26 |
JBoyer |
Ok. I wasn't certain since they tell libraries to set vendacct to their SAN also. so long as your org_unit_san matches their vendacct it doesn't make much difference. |
| 14:26 |
JBoyer |
I'll throw on a signoff after a quick test. |
| 14:28 |
berick |
oh and in some cases, the org-san is include as a separate part of the NAD+BY field |
| 14:31 |
Bmagic |
I've been meaning to investigate but we are having Ingram invoice issues. Can that be related to the new non-Ruby stuff? |
| 14:32 |
berick |
Bmagic: hard to say, but the new stuff is only resopnsible for sending orders |
| 14:32 |
berick |
it doesn't directly touch invoices |
| 14:32 |
berick |
possible a changed order could affect an invoice, though |
| 14:33 |
Bmagic |
The invoice comes in but with no items |
| 14:34 |
Bmagic |
looking at the EDI message, there are tons of items |
| 14:38 |
* berick |
ponders a new biblio.record_entry.last_merge_date field |
| 14:43 |
|
collum_ joined #evergreen |
| 15:15 |
|
collum joined #evergreen |
| 15:23 |
|
collum joined #evergreen |
| 15:43 |
|
mmorgan joined #evergreen |
| 15:51 |
|
collum_ joined #evergreen |
| 16:11 |
rlefaive |
Hey #evergreen we’re curious about ways of speeding up Vandelay. We have batches over 100k, that we’d like to be able to load, but the matching query (with a match set on the 020) takes about 10s/record. Do you know folks who do the matching external to EG? |
| 16:14 |
|
collum joined #evergreen |
| 16:19 |
Dyrcona |
rlefaive: I've usually done the whole thing, matching and load external to Vandelay. |
| 16:19 |
Dyrcona |
Best I've ever been able to do is about 4 seconds to find a match and 2 seconds for the db update. |
| 16:20 |
rlefaive |
oooh, Dyrcona thanks! Are there available scripts for that? (I’ve heard of marc_stream_importer.pl but i think it just loads records into Vandelay, letting vandelay do the matching if the queue wants to) |
| 16:21 |
Dyrcona |
rlefaive: Nothing that I've shared publicly, and most of what I have now are pretty specific to how C/W MARS manages URIs. |
| 16:22 |
rlefaive |
Dyrcona… ooh, nice… when you say URIs are you refering to matching 856s? |
| 16:22 |
Dyrcona |
Sort of. We usually match on 035 and 020. |
| 16:23 |
Dyrcona |
Then, I pull the marc out and mess with the 856s in Perl. |
| 16:24 |
rlefaive |
Dyrcona: i see. interesting. For some reason our match sets ignore the 035, but that seems like a good identifier to use. |
| 16:24 |
Dyrcona |
I get best results from building a tsvector of the ISBNs in the incoming record and doing a ts_search on the index_vector column of metabib.real_full_rec. |
| 16:25 |
Dyrcona |
Well, our code does two searches and adds up points based on the matches, choosing the first record with the highest score. |
| 16:25 |
Dyrcona |
"First" only being operative in the event of ties. |
| 16:25 |
Dyrcona |
We also match on item_type and item_form, it looks like. |
| 16:26 |
rlefaive |
Dyrcona: nice! Do you do ever attempt to distinguish a record for, say, a book on one platform, with a record for that same book on a different platform? We’ve made the decision to manage individual records for different platforms (because we often have to do bulk deletes). |
| 16:27 |
Dyrcona |
rlefaive: Not really. We put them all in one record. That's not my preference, but it is supposed to be good for patrons. |
| 16:27 |
rlefaive |
Dyrcona: yes, it would be! Awkward to manage for us, though. |
| 16:27 |
Dyrcona |
I've made tables to match records from different sources. |
| 16:28 |
Dyrcona |
Yes, it is awkward, but a vendor->record mapping table and some views help. |
| 16:29 |
rlefaive |
Dyrcona: I kind of wonder about treating 856’s kind of like “holdings” in that we shoudl be able to add and remove them (and their license/purchase info) separate from the MARC? |
| 16:29 |
rlefaive |
Dyrcona: tables++ |
| 16:29 |
Dyrcona |
rlefaive: Yes, some ILS's might do it that way. |
| 16:29 |
rlefaive |
Dyrcona: I’ve never seen one that does |
| 16:29 |
Dyrcona |
rlefaive: Actually, I have this script in my evergreen_utilities repo on github now that I'm looking at the code. |
| 16:30 |
Dyrcona |
https://github.com/Dyrcona/evergreen_utilities/blob/master/perl/loaderecords.pl |
| 16:30 |
Dyrcona |
That's the main one we use. |
| 16:31 |
Dyrcona |
I have two copies of it, more or less identical, it turns out. |
| 17:01 |
|
mmorgan left #evergreen |
| 17:06 |
|
jvwoolf left #evergreen |
| 18:06 |
phasefx |
so the perl live test failure, I know which commit instigates the change in behavior (which is a different distribution of generated concerto item barcodes), but I see no reason why it would. For expediency, I could update to test to expect the "new normal", but I really want to understand under what conditions assets_extras.sql will produce different output |
| 18:09 |
phasefx |
it looks like it's not really _extras.sql fault; eyes on assets_concerto.sql.. there are some barcodes that exist in one branch or the other (patch and no-patch) |
| 18:27 |
|
troy__ joined #evergreen |
| 18:31 |
pinesol_green |
News from qatests: Failed Running perl live tests <http://testing.evergreen-ils.org/~live> |
| 19:43 |
bshum |
phasefx: That's one of the problems with the concerto dataset we were trying to isolate and explain better during the Hackaway |
| 19:44 |
bshum |
phasefx: We definitely notice it happening whenever bib records get added or removed in the test dataset |
| 19:44 |
bshum |
There's some other cases too |
| 19:45 |
bshum |
Changing the resulting test is certainly the easiest way out of those, but what we really need to do is potentially come up with ways of keeping the generated values more consistent. Or perhaps pinning specific copies to certain bibs, etc. to perform tests with. |
| 19:45 |
bshum |
There was some brief discussion about it, but we hadn't decided on the best way forward at the meeting. |
| 19:45 |
bshum |
I'm sure we're all open to ideas :D |
| 19:46 |
bshum |
What was the commit that threw things off? |
| 21:00 |
|
serflog joined #evergreen |
| 21:00 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org |
| 21:01 |
csharp |
ok - back |
| 22:04 |
* jeff |
waves |
| 22:04 |
jeff |
csharp: are you also/now also working on the community lists server? |
| 22:07 |
jeff |
csharp: nevermind. someone just ack'd the alert that had prompted me to ask. :-) |
| 23:30 |
|
Jillianne joined #evergreen |
