| Time |
Nick |
Message |
| 00:46 |
senator |
curse you serials. just tried to type the word 'issue' in a totally unrelated context and my fingers typed 'issuance' |
| 01:53 |
|
rsinger joined #evergreen |
| 04:53 |
|
zxiiro joined #evergreen |
| 05:08 |
|
rsinger joined #evergreen |
| 07:46 |
|
mrpeters joined #evergreen |
| 08:34 |
|
kbeswick joined #evergreen |
| 08:40 |
|
b_bonner_ joined #evergreen |
| 08:43 |
|
Shae joined #evergreen |
| 08:46 |
|
ericar joined #evergreen |
| 08:49 |
dbs |
csharp: wild stab at hold processing, sans any data other than the different hold types that now exist, would be the need for an index on action.hold_request.hold_type (possibly in a compound index; slow queries / plans would bear that out) |
| 08:51 |
dbs |
Rereading the bug, meh, that's probably a totally off-base assumption. Ignore me |
| 08:58 |
csharp |
dbs: thanks for the theory! I'm open to any temporary fixes/workarounds at this point |
| 08:58 |
csharp |
e.g. if adding an index somewhere helps at all, I'll do it ;-) |
| 09:33 |
|
RoganH joined #evergreen |
| 09:42 |
|
keynote2k joined #evergreen |
| 09:52 |
|
yboston joined #evergreen |
| 10:10 |
|
remingtron joined #evergreen |
| 10:12 |
|
collum joined #evergreen |
| 10:36 |
senator |
csharp: logs with timing |
| 10:36 |
csharp |
senator: yeah - that's what I'm trying to do now - thanks for the suggestion |
| 10:37 |
senator |
if you can get a log trace of a single hold placement (which as you know invokes the targeter for that specific hold) that's granular enough to show us more precisely where the slow part is |
| 10:37 |
senator |
yeah |
| 10:38 |
csharp |
I've got one with DEBUG enabled on our test server |
| 10:38 |
csharp |
I'm trolling through it |
| 10:45 |
RoganH |
I change windows and all I see is chsarp saying something about trolling. It's going to be that kind of day, eh? |
| 10:54 |
* csharp |
IS IN UR IRC CHANNEL TROLLIN U LOL LOL LOL |
| 10:54 |
jeff |
@decide Totally Awesome District Library or Trolling All Day Long |
| 10:54 |
pinesol_green |
jeff: Mr. Spock: Something fascinating just happened. |
| 10:55 |
jeff |
alas. |
| 10:55 |
|
book` joined #evergreen |
| 10:55 |
csharp |
jeff++ |
| 11:10 |
|
krvmga joined #evergreen |
| 11:37 |
csharp |
okay looks like the call is CALL: open-ils.actor open-ils.actor.ou_setting.ancestor_default that gets called for every OU (that owns a copy of the target bib?) |
| 11:39 |
csharp |
sorry - CALL: open-ils.actor open-ils.actor.ou_setting.ancestor_default <ou.id>, circ.holds.org_unit_target_weight |
| 11:40 |
berick |
we could refactor some of that.. use the cstore variant, fetching in batch, .. |
| 11:40 |
csharp |
oh, and then it does CALL: open-ils.actor open-ils.actor.ou_setting.ancestor_default 117, circ.holds.target_when_closed for a bunch of units too |
| 11:41 |
csharp |
the request I'm looking at took 80 seconds, btw |
| 11:41 |
berick |
holy cow |
| 11:41 |
csharp |
yeah - that was a self-placed hold |
| 11:41 |
senator |
csharp: if possible (and i'm sure you'll want to do some redacting of authtokens, barcodes, and IPs) a pastebin of the log would be awesome |
| 11:42 |
csharp |
senator: yeah - I'm trying to make sure I don't paste anything private - looking for authtokens, passwd hashes, etc. |
| 11:45 |
berick |
csharp: you can look for 32-character words (md5 authtokens and password hashes) w/ something like: grep -w '\w\{32\}' filename |
| 11:46 |
csharp |
berick: excellent - thanks |
| 11:47 |
csharp |
http://pastebin.com/6LCW2Luf |
| 11:48 |
csharp |
this is at loglevel 3 on our live server, btw |
| 11:48 |
csharp |
I can do one with DEBUG enabled on our test server if that helps |
| 11:50 |
berick |
wonder what's happening between 11:01:04 and 11:01:13 |
| 11:51 |
|
sylvar joined #evergreen |
| 11:52 |
berick |
that is a lot of OUS calls. just switching to the cstore / stored-proc variant would help a lot |
| 11:54 |
csharp |
I can see how this wouldn't have manifested itself in an instance with fewer Ous |
| 11:54 |
berick |
yeah |
| 11:57 |
csharp |
that gap looks like this on the test server (different hold): http://pastebin.com/YmC7pUNq |
| 11:58 |
csharp |
(between Processing hold blah... and when it starts checking OU settings |
| 11:58 |
csharp |
) |
| 12:00 |
berick |
huh, wonder which of those is taking so long on your prod servers. I take it the prod hold is on a popular record with lots of copies? |
| 12:04 |
csharp |
lemme look |
| 12:06 |
csharp |
227 total copies - 4 current holds |
| 12:07 |
csharp |
http://gapines.org/eg/opac/record/5606034 - "Calculated in Death" - apropos title ;-) |
| 12:07 |
berick |
heh |
| 12:08 |
csharp |
I'll place a hold on it in our test server and see what the log output is there |
| 12:10 |
tsbere |
I wonder if we have similar problems when records have a couple hundred copies. We appear to have less than 300 total records with >100 copies, actually... |
| 12:13 |
csharp |
whoa 22968 lines for that threadtrace |
| 12:13 |
csharp |
but it took 73 seconds to process |
| 12:13 |
tsbere |
Hmmm. 48% of our records have ONE copy. >_> |
| 12:34 |
senator |
csharp: if you're feeling saucy, on your test system, |
| 12:34 |
senator |
you might try working/collab/senator/slow-targeter-try-faster-settings-lookup |
| 12:34 |
* csharp |
is feeling saucy and SASSY |
| 12:34 |
senator |
that has two commits |
| 12:34 |
|
rsinger joined #evergreen |
| 12:34 |
senator |
to basically do what berick suggested and speed up the ou setting lookups |
| 12:34 |
csharp |
senator: excellent - I'll give it a shot |
| 12:35 |
senator |
might shave off some time (there could be other slow parts still, but i agree you seem to have identified a big part) |
| 12:35 |
berick |
senator++ # man of action |
| 12:35 |
csharp |
senator++ |
| 12:35 |
sseng |
what is marc tag 905, subfield u? tried to look around the web but can't seem to find anything definitive |
| 12:36 |
csharp |
@marc 905 |
| 12:36 |
pinesol_green |
csharp: unknown tag 905 |
| 12:36 |
senator |
berick++ knowing the direction |
| 12:37 |
dbs |
sseng: 9XX are undefined, reserved for local use |
| 12:37 |
dbs |
So... you get to ask whoever created the record |
| 12:37 |
|
mrpeters left #evergreen |
| 12:37 |
senator |
and csharp++ for trial by fire :-) |
| 12:37 |
dbs |
senator++ |
| 12:37 |
dbs |
berick++ |
| 12:37 |
dbs |
csharp++ |
| 12:38 |
sseng |
dbs: oh i see. it's just that in function vandelay.overlay_bib_record, there is a check for it |
| 12:38 |
sseng |
dbs: and for all purposes, it comes out null |
| 12:43 |
dbs |
sseng: ah, looks like Evergreen's local use is to put add/delete/replace rules there |
| 12:44 |
|
BullSherd joined #evergreen |
| 12:44 |
|
BullSherd left #evergreen |
| 12:44 |
sseng |
dbs: in that function, it is used like this: editor_string := (oils_xpath('//*[@tag="905"]/*[@code="u"]/text()',v_marc))[1]; |
| 12:45 |
sseng |
dbs: and it looks like editor string then gets treated like a 'barcode' to get an id to populate editor_id |
| 12:47 |
sseng |
dbs: just thought it strange how there could be a user's barcode in the marc |
| 12:48 |
dbs |
sseng: oh, I think that's meant to record who updated the record? |
| 12:49 |
dbs |
that is, the "editor" of the record |
| 12:50 |
dbs |
could be user barcode, or usrname |
| 12:51 |
sseng |
dbs: that's sounds like it, now curious to see where in eg code the barcode gets written to that subfield. |
| 12:52 |
sseng |
dbs: thanks a bunch for your help! |
| 12:52 |
|
smyers_ joined #evergreen |
| 12:54 |
csharp |
senator: I saw that speed up from 73 to 61 seconds on the test server after applying the patches and restarting opensrf |
| 12:54 |
csharp |
Method duration for [open-ils.storage.action.hold_request.copy_targeter]: 59.706 |
| 12:55 |
csharp |
Method duration for [open-ils.circ.holds.test_and_create.batch]: 61.294 |
| 12:55 |
csharp |
^^after |
| 12:55 |
csharp |
vv before |
| 12:55 |
csharp |
Method duration for [open-ils.circ.holds.test_and_create.batch]: 71.550 |
| 12:56 |
csharp |
Method duration for [open-ils.storage.action.hold_request.copy_targeter]: 73.370 |
| 12:56 |
csharp |
the frontend still times out, but it's better on the server side |
| 12:58 |
* dbs |
wonders about caching the COUST rather than fetching it fresh every time |
| 12:59 |
eeevil |
sseng: re barcode in 905u, evergreen doesnt write that, it reads it from external tools |
| 13:00 |
* eeevil |
disappears as quickly as he appeared |
| 13:00 |
sseng |
eeevil: ooh i see. so, might not be a good idea to comment that check out, thanks! |
| 13:01 |
|
Dyrcona joined #evergreen |
| 13:02 |
Dyrcona |
More pgtap questions. |
| 13:02 |
Dyrcona |
Should a test file related to a database upgrade script go in t or t/regress? I assume t, but thought I would ask. |
| 13:15 |
|
rsinger joined #evergreen |
| 13:20 |
|
rfrasur joined #evergreen |
| 13:25 |
|
RoganH joined #evergreen |
| 13:27 |
Dyrcona |
Hmm. Also, what about a branch with two upgrade scripts? So far I'm putting the tests in a single .pg file. |
| 13:28 |
Dyrcona |
The scripts could be merged into one upgrade script, I guess. |
| 13:31 |
|
ericar joined #evergreen |
| 13:54 |
tsbere |
senator / csharp: Thinking about holds and the stuff being done, wouldn't most of the lookups in the targeter not affect placement at all? respond_complete happens *before* the hold creation process fires off a blind request to the copy targeter after all... |
| 13:58 |
* csharp |
has no idea... |
| 13:59 |
* senator |
thinks and looks |
| 13:59 |
senator |
csharp: also, cool, thanks for testing that, at least it's a small win. more to do i see... |
| 13:59 |
csharp |
senator: happy to help! |
| 14:02 |
|
ktomita_ joined #evergreen |
| 14:05 |
senator |
tsbere: so you mean the respond_complete near the end of sub create_hold aka open-ils.circ.holds.create.override ? |
| 14:06 |
senator |
if so, i think the thing is that's not the api method the tpac calls |
| 14:06 |
senator |
iiuc |
| 14:06 |
senator |
(but maybe the api method that is called should mimic the other in that respect (and is the other dead code and should it go?)) |
| 14:07 |
senator |
i see tpac code calling open-ils.circ.holds.test_and_create.batch instead |
| 14:09 |
* Dyrcona |
sings: "Let's do the 'rebase' again...." |
| 14:11 |
Dyrcona |
senator: Note tsbere is talking about the targeter and not tpac. |
| 14:12 |
tsbere |
senator: test and create batch ends up calling open-ils.circ.holds.create (or the .override variant) if the "test" succeeds |
| 14:12 |
senator |
right, well i thought we're talking about whether the targeter must be waited on at hold placement time |
| 14:12 |
Dyrcona |
Also, pgtap is easy. :) |
| 14:13 |
senator |
ah there it is, i see |
| 14:13 |
tsbere |
senator: And that leads us into create_hold, which is where the targeter comes into play. I think the problem with hold *placement* is the "test" phase of that, the call to open-ils.circ.title_hold.is_possible call |
| 14:13 |
Dyrcona |
senator: OK. I know we have some internal tickets, related to checkin, that we like to blame on holds code being slow but we've not figured out what exactly is the problem. |
| 14:14 |
* graced |
thinks eeevil would be helpful about now... |
| 14:14 |
* Dyrcona |
shuts up, so as not to confuse things. |
| 14:16 |
senator |
no actually if you already know something about it, let's all update the relevant launchpad bug |
| 14:16 |
senator |
i see 1185865 but what's that newest one? harder for me to find it than usual; gmail outage |
| 14:17 |
senator |
i'll note what i did with the ou setting lookup branch, but indeed that doesn't seem to be the fundamental problem at all |
| 14:17 |
csharp |
bug 1272316 |
| 14:17 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 2, heat: 10) [Undecided,New] https://launchpad.net/bugs/1272316 |
| 14:17 |
senator |
thanks csharp |
| 14:17 |
csharp |
we should probably mark the other as a duplicate (if bshum agrees that it is) |
| 14:18 |
senator |
oh i see you've already written some of it up |
| 14:19 |
csharp |
feel free to correct/elaborate though |
| 14:19 |
jeff |
14:12 US/Eastern ``We're investigating reports of an issue with Gmail. We will provide more information shortly.'' |
| 14:20 |
csharp |
jeff: oh boy |
| 14:21 |
dbs |
jeff: yeah. Just tried sending an email to the MARC list and was wondering what was going on :) |
| 14:21 |
csharp |
@who typed "google" into Google? |
| 14:21 |
pinesol_green |
csharp: Down time is a fact of business when you're a poor 501c3 corporation. |
| 14:21 |
rfrasur |
hah |
| 14:22 |
senator |
csharp: oh no corrections, just a request for more data https://bugs.launchpad.net/evergreen/+bug/1272316/comments/2 |
| 14:22 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 2, heat: 10) [Undecided,New] |
| 14:24 |
Dyrcona |
That down time thing was too funny! |
| 14:25 |
csharp |
@praise [dunno] |
| 14:25 |
* pinesol_green |
Sorry, that command is only available to Evergreen Premium™ Subscribers. Please upgrade your subscription ASAP! is kind and patient to newbies |
| 14:26 |
rfrasur |
jeff: are you also getting bunches of snow? snow and no gmail. apocalypse? |
| 14:26 |
* tsbere |
wonders where that praise came from |
| 14:27 |
csharp |
tsbere: I nested the @dunno within the @praise |
| 14:27 |
tsbere |
csharp: Fun. Confusing, but fun. |
| 14:27 |
csharp |
heh |
| 14:28 |
jeff |
s'no-more-gmail-pocalypse |
| 14:28 |
csharp |
jeff++ |
| 14:29 |
Dyrcona |
G+ says I've reached the end...of the Interent, I guess. |
| 14:36 |
rfrasur |
jeff++ |
| 14:38 |
Dyrcona |
So, another pgtap question. |
| 14:39 |
Dyrcona |
What should I do with views that were altered by the upgrade script? |
| 14:40 |
jeff |
as in, how should you test them? |
| 14:41 |
jeff |
sorry, in the context of pg_tap, i suppose that was a silly question on my part. |
| 14:42 |
* dbs |
doesn't understand the question |
| 14:42 |
tsbere |
Dyrcona: I think you can do tests as though you would for a table (columns and types for the columns) - Beyond that you may want to look at ensuring test data is there and pulling from the view to ensure you got the correct info, maybe? |
| 14:44 |
Dyrcona |
dbs: I'm working on tests for an upgrade script that alters existing view definitions. I'm also discovering that there is no easy way to check if a view definition (i.e. its underlying query) is correct. |
| 14:44 |
Dyrcona |
jeff: Basically, yes. |
| 14:44 |
Dyrcona |
Testing for the existence of the views is easy. |
| 14:45 |
Dyrcona |
Testing it the view has or hasn't certain columns is also easy. |
| 14:45 |
Dyrcona |
s/it/if/ |
| 14:45 |
csharp |
senator: https://bugs.launchpad.net/evergreen/+bug/1272316/comments/4 |
| 14:45 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 2, heat: 10) [Undecided,New] |
| 14:45 |
phasefx |
Dyrcona: test the views behavior with test data? |
| 14:45 |
senator |
csharp++ kmlussier++ |
| 14:46 |
dbs |
Dyrcona: given that the view probably surfaced incorrect data before, and that's why it has been upgraded, wouldn't you just insert data into the underlying tables that you know would trigger the bad "before" case and test that the view now shows "good" data? |
| 14:46 |
dbs |
what phasefx said, only more verbose :) |
| 14:46 |
Dyrcona |
dbs: The views are being changed not because they were incorrect before, but because columns are disappearing from a base table. |
| 14:47 |
tsbere |
Dyrcona: In that case I would mainly focus on "the view does not have the column that went away" |
| 14:47 |
phasefx |
Dyrcona: I would still pick some data that exercised the boundaries of whatever query powered the view.. find data that should fall in and outside of the view |
| 14:47 |
phasefx |
if it is indeed the query you're concerned with |
| 14:50 |
jeff |
beyond testing a view for columns being present / not-present and testing data types of those columns, i think you have to use data to test the underlying query of a view. |
| 14:50 |
Dyrcona |
phasefx: I'll give that some thought. Since we're talking about billing and 8 views (3 or which are only modified if they exist), that could be a lot of test data. |
| 14:51 |
jeff |
i'm not sure that "view's definition is [SQL HERE]" is a good test. |
| 14:51 |
Dyrcona |
jeff: I'm not sure "view's definition is ...." is easily done. |
| 14:52 |
jeff |
i don't see a way, short of extending. i'm just saying "maybe there isn't an easy way because it's not a great test" :-) |
| 14:52 |
phasefx |
when it comes to testing structure (which I think is not being advocated here), I think we could do that better / more centrally for everything |
| 14:52 |
|
stevenyvr joined #evergreen |
| 14:52 |
Dyrcona |
tsbere: Also, I don't recall at this point if the view columns changed. It may only be from statements in many cases. |
| 14:53 |
Dyrcona |
jeff: I agree. |
| 14:53 |
dbs |
SELECT definition FROM pg_catalog.pg_views WHERE schemaname = blah, viewname = blah; # but I agree with data view |
| 14:53 |
Dyrcona |
Are there transactions in the concerto data, and are bills included? |
| 14:54 |
Dyrcona |
If yes && yes, I may just test the views in live_t? |
| 14:54 |
dbs |
Dyrcona: Yes, but you would need to run the fine generator to actually generate bills |
| 14:54 |
dbs |
So no |
| 14:54 |
jeff |
i am interested in having or creating sample bills and payments, fwiw. |
| 14:55 |
phasefx |
care would have to be taken if we use the fine generator for test data, because of the day's date changing |
| 14:55 |
jeff |
i have some pretty fun test cases from our live data. ;-) |
| 14:56 |
Dyrcona |
dbs: (I am not knocking automated tests.) I think that speaks to my arguments about the complexity of testing things in a system as complicated and why automated tests will never catch everything. |
| 14:56 |
jeff |
i think we could have bills and payments in the sample data without need for using the fine generator to create the bills. |
| 14:56 |
Dyrcona |
jeff++ |
| 14:56 |
phasefx |
could and should |
| 14:56 |
dbs |
Dyrcona: Jesus, man, I never claimed automated tests will catch everything! |
| 14:56 |
Dyrcona |
dbs: OK. :) |
| 14:57 |
Dyrcona |
I don't mean to start a war. |
| 14:57 |
dbs |
jeff: I'm pretty sure berick and I kicked that around but didn't want to insert artificial data that might end up not matching what the fine_generator would actually produce |
| 14:57 |
dbs |
Dyrcona: You should have just let me win |
| 14:57 |
Dyrcona |
dbs++ |
| 14:57 |
dbs |
Dyrcona++ |
| 14:58 |
Dyrcona |
dbs: I'm writing tests. I think you did win. :) |
| 14:58 |
* dbs |
was looking for a wrecking ball |
| 14:58 |
Dyrcona |
Yeah, I can see issues with bogus data that doesn't match fine generator. |
| 14:58 |
phasefx |
hrmm. I think historical bills are fair game if they do indeed match what non-artificial data for that point in time looks like |
| 14:58 |
jeff |
dbs: yeah. of course, you could use the fine generator to create the bills from the start, and use that static data for the insert of sample data, but then they wouldn't benefit from any upgrade scripts that would be expected to adjust/migrate (say, with numeric billing types, etc) |
| 14:59 |
jeff |
but at that time, it COULD be on the person making those changes to also change the sample data. |
| 14:59 |
* dbs |
thinks one branch he pushed had static fine data but that we opted not to commit that to master, for all those complex reasons |
| 14:59 |
phasefx |
:-/ |
| 14:59 |
jeff |
for one thing, in certain cases the sample data would no longer load... :-) |
| 15:00 |
jeff |
dbs: yeah, was that conversation on list or on irc, or did it happen elsewhere? |
| 15:00 |
jeff |
i seem to recall it, and that this is at least somewhat of a rehash. |
| 15:00 |
dbs |
irc or launchpad, or perhaps a mix of both |
| 15:02 |
Dyrcona |
I'll leave out those tests for now. I can come back and add them later. |
| 15:03 |
|
BlerenMen joined #evergreen |
| 15:03 |
|
BlerenMen left #evergreen |
| 15:03 |
Dyrcona |
I think I'll move on to tests for branches that just add settings and permissions. Those are simple. |
| 15:03 |
* phasefx |
remembers having this sort of pain with sample data to power the receipt template editor, and we see how that turned out :( |
| 15:03 |
keynote2k |
Hi, all. Tony from Software Freedom Conservancy here. I'm looking for photos of Evergreen Conference 2012 in Indiana to use in Conservancy's FY2012 annual report. Anyone have any photos I could use (ideally, under a Creative Commons license)? |
| 15:03 |
jeff |
but i'd still like to figure out a way of having the test data, so maybe we can revisit. |
| 15:03 |
keynote2k |
if so: privmsg me. Thanks! |
| 15:04 |
jeff |
phasefx: yeah, good example. the data was buried and drifted significantly. i've been thinking about receipts and receipt macros lately. :-) |
| 15:04 |
phasefx |
jeff: yeah, I'm doing a talk on it at the EG conference, so I'll probably get the itch soon to make it better first :) |
| 15:04 |
jeff |
i haven't reviewed the talks. what are you talking on? |
| 15:04 |
jeff |
oh, receipts? |
| 15:04 |
phasefx |
two talks, one for QA, and one for customizing receipt templates |
| 15:05 |
jeff |
ah. i see why those intersected for you, then. :-) |
| 15:05 |
phasefx |
QA talk: need more tests :) |
| 15:06 |
jeff |
"Please join me after the receipt printer talk in the atrium, where we will be destroying a series of receipt printers using various weapons and solvents." |
| 15:06 |
phasefx |
haha |
| 15:06 |
jeff |
now THERE'S a fund raising opportunity. |
| 15:07 |
* phasefx |
will be using a pdf printer for sanity |
| 15:07 |
jeff |
$25 for 30 seconds with the sledge hammer |
| 15:08 |
tsbere |
amazingly enough, for the most part, I don't hate the receipt printers themselves |
| 15:08 |
tsbere |
I generally find them fine |
| 15:08 |
tsbere |
Their *drivers*, on the other hand... |
| 15:09 |
dbs |
Should we make a general announcement at the conference that Windows XP will no longer be supported as of April 8th, 2014? |
| 15:09 |
* dbs |
imagines the shocked gasps |
| 15:09 |
rangi |
:) |
| 15:09 |
phasefx |
but we haven't upgraded to XP yet! |
| 15:09 |
dbs |
phasefx++ |
| 15:10 |
RoganH |
phasefx++ |
| 15:10 |
tsbere |
I actually had to tell someone to upgrade a windows 2000 machine that Evergreen stopped working on after a xulrunner update. <_< |
| 15:10 |
jeff |
tsbere: yes, but destroying a driver is not very cathartic, is it? |
| 15:11 |
RoganH |
tsbere: Windows 2000 was the last Windows I genuinely thought was good rather than acceptable |
| 15:11 |
tsbere |
jeff: Oh, but you don't take out frustration on the code. You find the person/people who WROTE the code. ;) |
| 15:11 |
jeff |
tsbere: yes, but destroying a person is not very legal, is it? :P |
| 15:11 |
tsbere |
(or replace the code you dislike, but in closed source drivers you can't do that, so...) |
| 15:13 |
* tsbere |
recalls one receipt printer driver that only worked if the OS was installed on the C drive and had not been upgraded from a previous version of windows due to hardcoded paths changing depending on if it was an upgrade or not... |
| 15:13 |
rangi |
jeff: seems fine if you are a govt |
| 15:16 |
jboyer-isl |
If you add a new set of coded value maps, do you need to do something more exotic than a standard reingest to populate them? |
| 15:16 |
jboyer-isl |
Or something altogether different? |
| 15:17 |
gmcharlt |
jeff: reminds me a library I once migrated -- their project manager wanted to drop the previous ILS's server off the roof |
| 15:17 |
gmcharlt |
I was never entirely sure just how serious he was |
| 15:18 |
jeff |
jboyer-isl: no reingest needed, iirc -- but probably an apache *possibly* opensrf restart? it's been a while, but i think someone else just recently discussed that. |
| 15:18 |
jeff |
gmcharlt: we have often joked about similar here. |
| 15:18 |
jeff |
gmcharlt: not limited to any one server or service or technology. |
| 15:19 |
jeff |
thermite... |
| 15:19 |
gmcharlt |
indeed |
| 15:19 |
gmcharlt |
this guy, however, was pretty close to actually doing it |
| 15:19 |
jboyer-isl |
jeff: That's doubly puzzling then. I actually added the ccvm in our 2.2 database thinking it did require a reingest, and now that it's been pg_dump/restored, upgraded, and reingested, using that ccvm (for marc form) returns 0 results for all queries. :/ |
| 15:19 |
gmcharlt |
had more to do with the hardware service contract than the software, as I recall |
| 15:20 |
jeff |
jboyer-isl: hrm. perhaps i'm not remembering correctly at all, then. |
| 15:20 |
tsbere |
jboyer-isl: I find myself needing more information before I can tell you where your issue is. |
| 15:21 |
tsbere |
for example, the ccvm entry you added |
| 15:21 |
jboyer-isl |
I'm pulling that up now. |
| 15:21 |
tsbere |
feel free to poke me directly if you want |
| 15:21 |
* csharp |
imagines police talking the guy down "Sir - please put down the server!" |
| 15:23 |
jboyer-isl |
tsbere: It may not end up being a lot of back and forth if what I've done sounds crazy. |
| 15:23 |
dbwells |
jboyer-isl: I'd think you would need a reingest (or a more targetted update of some kind) to populate a totally new attribute extraction. |
| 15:24 |
kmlussier |
keynote2k: I don't remember seeing a lot of photos from prevous conferences. |
| 15:24 |
tsbere |
jboyer-isl: Either way, your choice ;) |
| 15:24 |
jboyer-isl |
dbwells: That's what I thought, but this database has had a reingest run against it after this was defined. |
| 15:26 |
jboyer-isl |
I defined a new Record Attribute Definition for Form (This may be the part where questions are raised) so that I could then come up with custom labels for a Coded Value Map for that attribute. I didn't think it a good idea to mess with the default definitions too much. |
| 15:27 |
jeff |
ah. you didn't mention you'd added a new config.record_attr_definition :-) |
| 15:28 |
tsbere |
jboyer-isl: I went the route of "add a search_label field to coded value map" myself, which is in later versions of Evergreen. |
| 15:28 |
dbwells |
jboyer-isl: And how is your new record attribute defined? With the "Form" fixed field, or something else? |
| 15:29 |
jboyer-isl |
The Form fixed field. Just like the 'item_form' definition that we already had. |
| 15:29 |
jboyer-isl |
jeff: I had forgotten until I was looking into it again. :) |
| 15:30 |
dbwells |
yeah, I just assumed that's what he meant :) |
| 15:30 |
dbwells |
jboyer-isl: I guess the next thing I'd do is poke into metabib.record_attr and see if you see your field in the attrs hstore. |
| 15:31 |
jeff |
next thing you're going to tell me that we've had a wheelbarrow among our assets all along. |
| 15:31 |
jboyer-isl |
I didn't know where to look for them. I'll see what's going on there. |
| 15:33 |
kmlussier |
Wow! ESI's web site looks all shiny and new. When did that happen? |
| 15:40 |
jboyer-isl |
dbwells: The results of a "select * from metabib.record_attr limit 2;" lists 1 record with the new attribute and one without. The one with has it set to " ", which also doesn't help. |
| 15:45 |
jboyer-isl |
the syntax for selecting an hstore key is a pain to look up. |
| 15:45 |
dbwells |
jboyer-isl: we have some " " blank values for item_form, so I think that's alright. Assuming you named your new attr 'form' does this return anything useful?: select * from metabib.record_attr where attrs->'form' <> ' ' LIMIT 5; |
| 15:47 |
dbwells |
Or, for ease of looking: select attrs->'form' from metabib.record_attr where attrs->'form' <> ' ' LIMIT 5; |
| 15:47 |
jboyer-isl |
There we go. Yes, I got back 5 results, the usual 'b', 'd', etc. |
| 15:48 |
dbwells |
jboyer-isl: well, I guess the good news is your record attribute definition is working to at least some degree. |
| 15:48 |
* Dyrcona |
is dealing with the "joys" of basing branches off of other branches that change a lot. |
| 15:50 |
jboyer-isl |
Now I'm wondering if I have to do some more research on the Form field, because some of the defs have 2 characters, and those are returning 0 results in the db. |
| 15:53 |
dbwells |
jboyer-isl: So some selections *are* working? I know the old 'format' selector let you pile in multiple codes (e.g. format(ab) for both 'a' and 'b'), but I don't think the record attr based stuff has that ability (yet). |
| 15:54 |
dbwells |
Some of us resurrected the old 'format' selector by making a fake ccvm, but that doesn't generalize. |
| 15:55 |
dbwells |
It might do what you want here, though. |
| 15:56 |
jboyer-isl |
I think that's the way it's going to go. There was some kind of hard-coded format selector that we were using, and I had hoped to move to something more generic. Looks like that's not going to work. |
| 15:57 |
tsbere |
jboyer-isl: Two characters? As in, say, ij for "i or j"? |
| 15:58 |
tsbere |
MVLC does that for some things. Due to how TPAC uses them in particular we go with "i,j", which gets dropped in literally when turned into a search string. |
| 15:58 |
jboyer-isl |
Yes, or 'at-d' for large print books. |
| 15:58 |
tsbere |
at-d is actually two different indexes |
| 15:59 |
tsbere |
and as such doesn't work in a single ccvm entry |
| 15:59 |
* berick |
points out https://bugs.launchpad.net/evergreen/+bug/1269911 |
| 15:59 |
pinesol_green |
Launchpad bug 1269911 in Evergreen "Composite Record Attributes" (affected: 1, heat: 6) [Wishlist,New] - Assigned to Mike Rylander (mrylander) |
| 16:00 |
tsbere |
berick: If you want, add a ", yet" to my statement. At the moment it still holds true :P |
| 16:00 |
jboyer-isl |
I suppose knowing a bit more about cataloging may have helped with this. |
| 16:00 |
berick |
yes, of course |
| 16:00 |
berick |
my response being to tsbere's comment, not jboyer-isl's ;) |
| 16:00 |
* dbwells |
didn't know about the comma trick, and may use that at some point |
| 16:00 |
jeff |
doesn't work with a single ccvm entry, but does work with something like http://catalog.tadl.org/eg/opac/results?query=mystery&qtype=keyword&fi%3Aformat=at-d&locg=22 |
| 16:01 |
jeff |
but that's using a "hardcoded" format selector, not dynamic ccvm |
| 16:02 |
jeff |
essentially, <select id='item_format_selector' name='fi:format'> |
| 16:02 |
jeff |
instead of <select id='item_type_selector' name='fi:item_type'> |
| 16:03 |
jboyer-isl |
Given that the format selector still works (and that's how our current version works) I'll be reverting that change first thing Monday. |
| 16:03 |
dbwells |
So, by the way, don't label a ccvm as 'format' and expect it to work :) It's reserved. |
| 16:03 |
jeff |
heh |
| 16:04 |
jboyer-isl |
Oh, no. I'm not planning to outsmart it; I don't mind swinging the hard-code hammer in this case, I just don't want to start thinking that everything looks like a nail. :) |
| 16:04 |
jeff |
that selector then has at-d for Large Print Books, at-s for E-Books (depending on how cataloged!), and the ever-hackish mVG- for Video Games |
| 16:05 |
jboyer-isl |
Thanks for the help guys, at least I didn't run down the wrong path for too long. |
| 16:05 |
jboyer-isl |
tsbere++ |
| 16:05 |
jboyer-isl |
dbwells++ |
| 16:06 |
jboyer-isl |
jeff++ |
| 16:06 |
jeff |
oh dear. |
| 16:07 |
jeff |
i just went from "huh, what did I do there with mVG-?" to "ow, my eyes!" |
| 16:08 |
jeff |
"This is a little bit of a hack." https://github.com/tadl/Evergreen_templates_tadlskin/commit/cc4fc79f79c7984dcd46367a677cce664cb9d9b7 |
| 16:09 |
jboyer-isl |
Talk about dedication to the cause, heh. I'd just recommend people add "game" to a keyword row. :D |
| 16:11 |
jeff |
i am happy to say that we were able to omit several local hacks in our 2.2 -> 2.5 upgrade process. |
| 16:18 |
|
jboyer-isl joined #evergreen |
| 16:18 |
* tsbere |
hates listening to fire alarms go off |
| 16:23 |
tsbere |
Third time today, and second time in the past hour. <_< |
| 16:23 |
tsbere |
though I suppose I should be happy it isn't this building... |
| 16:25 |
* Dyrcona |
wishes he had reworded a commit during his last rebase -i, but oh well. |
| 16:25 |
* Dyrcona |
considers it too late now. |
| 16:46 |
kmlussier |
Dyrcona: I'm sure I could look through the commits myself, but I'm lazy. Do I need to add a release notes entry for the negative balance work? |
| 16:46 |
kmlussier |
If so, I'll add a note to the bug just so I don't forget. |
| 16:47 |
Dyrcona |
kmlussier: Oh yeah. I forgot about releasenotes. |
| 16:47 |
kmlussier |
Dyrcona: No worries. I can do it. I think I offered to do so a while back. |
| 16:48 |
Dyrcona |
You could add it and push to a collab branch and then update the bug, or I could pull your commit into the branch on the bug. |
| 16:48 |
* Dyrcona |
puts his chef hat on to roast a chicken and do some dishes. |
| 16:49 |
* senator |
puts on firegloves to roast chickens |
| 16:49 |
senator |
but given current weather in Dyrcona's locale, can't blame him for not |
| 16:53 |
kmlussier |
@wunder 02771 |
| 16:53 |
pinesol_green |
kmlussier: The current temperature in Ladd Observatory, Providence, Rhode Island is 15.1°F (4:52 PM EST on January 24, 2014). Conditions: Partly Cloudy. Humidity: 44%. Dew Point: -2.2°F. Windchill: 8.6°F. Pressure: 30.21 in 1023 hPa (Steady). |
| 16:54 |
kmlussier |
Hey, it's balmy! We're in double digits. No reason why we can't do some outdoor grilling. |
| 16:55 |
senator |
:-) that's the spirit! |
| 16:56 |
jeff |
@wunder ktvc |
| 16:57 |
pinesol_green |
jeff: The current temperature in Traverse City, Michigan is 17.6°F (4:53 PM EST on January 24, 2014). Conditions: Light Snow. Humidity: 81%. Dew Point: 12.2°F. Windchill: 6.8°F. Pressure: 29.53 in 1000 hPa (Rising). Winter Weather Advisory in effect until 5 am EST Saturday... |
| 16:58 |
|
ElliotFriend joined #evergreen |
| 17:00 |
ElliotFriend |
@wunder 63033 |
| 17:00 |
pinesol_green |
ElliotFriend: The current temperature in Jost Farm, Florissant, Missouri is 35.4°F (4:00 PM CST on January 24, 2014). Conditions: Scattered Clouds. Humidity: 26%. Dew Point: 3.2°F. Windchill: 26.6°F. Pressure: 30.05 in 1018 hPa (Falling). |
| 17:14 |
ElliotFriend |
Dyrcona: Did we talk a couple (few) months back about using Git to push EG upgrades from a laptop to testing to production? |
| 17:14 |
ElliotFriend |
Or was that someone else? |
| 17:25 |
Dyrcona |
That was probably me. |
| 17:26 |
ElliotFriend |
Any chance you remember when that was? I'm trying to find the conversation for reference, but for the life of me can't |
| 17:27 |
Dyrcona |
I don't really remember exactly when that was. |
| 17:29 |
kmlussier |
ElliotFriend: Did you try the search feature from here? http://irc.evergreen-ils.org/evergreen/ |
| 17:29 |
ElliotFriend |
didn't really think you would, but thought it wouldn't hurt to check |
| 17:29 |
ElliotFriend |
kmlussier: have been for about an hour haha |
| 17:29 |
kmlussier |
Ah, ok. |
| 17:29 |
ElliotFriend |
I'm starting to worry that I imagined the whole thing lol |
| 17:30 |
* eeevil |
pokes his head in ... jeff: re your conversation at 4pm Estern re the format filter, I have a present for you (and jboyer-isl): https://bugs.launchpad.net/evergreen/+bug/1269911 (code coming very soon, atop https://bugs.launchpad.net/evergreen/+bug/1269141 ) |
| 17:30 |
pinesol_green |
Launchpad bug 1269911 in Evergreen "Composite Record Attributes" (affected: 1, heat: 6) [Wishlist,New] - Assigned to Mike Rylander (mrylander) |
| 17:30 |
pinesol_green |
Launchpad bug 1269141 in Evergreen "Multi-valued Record Attributes" (affected: 1, heat: 6) [Wishlist,New] - Assigned to Mike Rylander (mrylander) |
| 17:30 |
jeff |
eeevil: i've been watching with interest. :-) |
| 17:31 |
Dyrcona |
ElliotFriend: Looks like it was December 5. |
| 17:34 |
ElliotFriend |
Dyrcona: You're my hero!!! |
| 17:34 |
ElliotFriend |
I badly need to work on my google/search skills, apparently |
| 17:35 |
Dyrcona |
I search my local IRC logs for your handle. |
| 17:36 |
ElliotFriend |
Makes sense, halfway through my search I turned on logging in Xchat :-) |
| 17:54 |
ElliotFriend |
Have a good weekend, everyone. Thanks again, Dyrcona!! |
| 18:20 |
|
jtaylorats joined #evergreen |
| 18:21 |
jtaylorats |
Quick question...working on migrating to evergreen and had a quick question. It appears that callnumber prefixes are required...but what does one do if most of the records don't have prefixes? |
| 18:21 |
jtaylorats |
...or suffixes (not sure if they are required yet)? |
| 18:21 |
kmlussier |
jtaylorats: prefixes aren't required |
| 18:22 |
jtaylorats |
When doing the "Insert it says the field cannot be NULL. |
| 18:22 |
jtaylorats |
Do I assign a blank string instead of NULL to get around the problem. |
| 18:22 |
jtaylorats |
It is a database level constraint. |
| 18:24 |
bshum |
There's usually a prefix that's blank ''. |
| 18:25 |
bshum |
Use that ID I would imagine? |
| 18:25 |
kmlussier |
bshum: Looking in one of my databases, I see -1. |
| 18:25 |
jtaylorats |
Okay...so just set them to -1. |
| 18:25 |
jtaylorats |
? |
| 18:26 |
kmlussier |
Yes, that's what it looks like. In asset.call_number_prefix, -1 is blank. |
| 18:26 |
jtaylorats |
But that won't work because of owning library. |
| 18:26 |
jtaylorats |
will it? |
| 18:26 |
kmlussier |
We've set suffixes to -1 too. |
| 18:27 |
jtaylorats |
Will it then think all those are owned by that one library? |
| 18:27 |
kmlussier |
jtaylorats: Well, the consortium owns -1. But a call number for a branch can use a prefix that's owned by the consortium. |
| 18:27 |
jtaylorats |
Okay. |
| 18:28 |
jtaylorats |
I'll give it a go and see what happens. Thanks. |
| 18:28 |
bshum |
Ownership of a volume is defined on the owning_lib field not by the prefix. |
| 18:29 |
jtaylorats |
Okay...wasn't sure how the owning_lib in the prefix table related to ownership of the item. |
| 18:32 |
jtaylorats |
Another question since I'm on....When loading the bib records via PSQL I get an error on some saying that one of the WIN1252 characters doesn't have an equivalent in UTF-8 and it drop the records but doesn't write it to the log. If I do the same insert via the Admin tool it goes in fine. Is this a known problem...something I'm missing? |
| 18:32 |
jtaylorats |
I'm probably not going to use PSQL for the next load but was curious. |
| 18:38 |
jtaylorats |
Couldn't find any reference to such an error anywhere. |
| 18:42 |
bshum |
I don't have much experience in that area, so I'm afraid you will have to wait for someone else. |
| 18:43 |
Dyrcona |
jtaylorats: How are you converting the MARC records to UTF-8 and what are they doing having WIN1252 characters in them? (As if I didn't know that all MARC records suck.) |
| 18:44 |
jtaylorats |
I thought they were in UTF-8 already. Using MarcEdit to convert them to MarcXML. Have been trying to figure out if I missed a step somewhere. Maybe I need to do something a bit more explicit during the prepping phase. Thought it was covered but apparently not. |
| 18:45 |
jtaylorats |
Hard to say why those characters are in there. |
| 18:45 |
Dyrcona |
Oh, its easy to say why the characters are in there: Most software that works with MARC records just plain sucks. |
| 18:46 |
Dyrcona |
When I load records I usually run them through some Perl code to convert them to MarcXML, convert the charset if necessary, and to "scrub" the records of control characters and other junk, first. |
| 18:47 |
jtaylorats |
Partly curious why the admin tool has no problem with the insert. Can't say for sure but I don't think it scrambled anything. |
| 18:47 |
jtaylorats |
I'll have to do some more checking. This is a test load and not worrying about it at the moment but need to cover that base before the next load. |
| 18:48 |
jtaylorats |
Thanks all. |
| 18:48 |
jtaylorats |
Need to get out of here. |
| 18:48 |
jtaylorats |
Bye for now. |
| 18:48 |
jtaylorats |
Hopefully one day I can answer a question for someone :-) |
| 18:49 |
jtaylorats |
...and maybe it will even be the right answer ;-) |
| 18:50 |
jtaylorats |
WooHoo!!! Looks like the server went down....that means I can quit for the night. |
| 20:14 |
|
timhome joined #evergreen |
| 20:26 |
|
rsinger joined #evergreen |
| 23:05 |
|
zerick joined #evergreen |
| 23:41 |
|
rsinger joined #evergreen |
