Evergreen ILS Website

IRC log for #evergreen, 2014-01-24

| 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
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-targ​eter-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.ho​ld_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.ho​ld_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/eve​rgreen/+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/eve​rgreen/+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/res​ults?query=mystery&amp;qtype=keywor​d&amp;fi%3Aformat=at-d&amp;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_tadlsk​in/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

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