| Time |
Nick |
Message |
| 03:04 |
|
tsbere joined #evergreen |
| 03:23 |
|
Bmagic joined #evergreen |
| 03:48 |
|
tsbere joined #evergreen |
| 04:16 |
|
Bmagic joined #evergreen |
| 05:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 07:10 |
|
agoben joined #evergreen |
| 07:15 |
|
rjackson_isl joined #evergreen |
| 08:39 |
|
mdriscoll joined #evergreen |
| 08:52 |
|
bos20k joined #evergreen |
| 08:54 |
|
collum joined #evergreen |
| 08:58 |
|
Dyrcona joined #evergreen |
| 09:05 |
|
rlefaive joined #evergreen |
| 09:15 |
Bmagic |
jeff: I think I can handle the rest. I just wondered if the reporter could find bibs that lacked a tag. I use nullable? |
| 09:20 |
|
yboston joined #evergreen |
| 09:36 |
Dyrcona |
Looking for something that isn't there is a logical contradiction. :) |
| 09:38 |
|
maryj joined #evergreen |
| 09:38 |
Dyrcona |
Bmagic: I would not try that in the reporter, but then I never try anything in the reporter... Every time I do, I choke the db server nearly to death. |
| 09:50 |
Dyrcona |
Here's a question: Why does the actor.org_address table have an org_unit column, when the org_unit table links to org_address via id? |
| 09:51 |
Dyrcona |
And, the prompt for this question is that someone came into my office this morning wondering why the org_units in the org_adress table do not match up to the org_units that link to the addresses. |
| 09:52 |
|
jvwoolf joined #evergreen |
| 09:52 |
Dyrcona |
That wasn't there question in so many words, but that was the cause of their question. |
| 09:53 |
Dyrcona |
We also don't seem to have any issues because the aoa.org_unit != aou.id of the aou that links to aoa via one of its address ids. |
| 09:54 |
Dyrcona |
I'm guessing that aoa.org_unit isn't used anywhere, but haven't looked. |
| 09:54 |
csharp |
Bmagic: theoretically, you could do a left join ("Parent" in nullability-speak) from Bib Record to the metabib.full_rec table (don't remember the reporter label for that) others may have a better idea |
| 09:55 |
csharp |
our cataloger has wanted something similar before to identify "incomplete" bibs |
| 09:56 |
* Dyrcona |
has recently found that left joins to mrfr can be slow, but that's basically how I'd do it. |
| 09:57 |
Dyrcona |
Oh, and upshot of my Perl threads experiment yesterday is, Don't do it, kids. |
| 09:58 |
Dyrcona |
MARC::File::XML is not thread safe because Encode.pm is not thread safe. |
| 09:58 |
Dyrcona |
@blame 9 Encode.pm |
| 09:58 |
pinesol_green |
Dyrcona: Encode.pm is why we can never have nice things! |
| 10:20 |
berick |
can anyone point me at the docs that form the basis for the authority control set mappings, specifically LoC? |
| 10:24 |
jeff |
"You map that way so often. I wonder what your basis for comparison is." |
| 10:30 |
|
jvwoolf joined #evergreen |
| 10:42 |
Dyrcona |
berick: You could start here: http://www.loc.gov/marc/authority/ |
| 10:48 |
berick |
Dyrcona: yeah I started there... did not find what I was looking for. |
| 10:48 |
|
Christineb joined #evergreen |
| 10:48 |
berick |
i'm sure it's in there somewhere |
| 10:51 |
abneiman |
berick: one of these maybe? https://www.loc.gov/standards/mods/mods-conversions.html |
| 10:55 |
Dyrcona |
berick: I don't think there is a simple document for those. I think it comes right out of the authority field specifications. |
| 10:57 |
berick |
Dyrcona: i'm happy to dig if I'm digging in the right place. and i'm probably looking right past it, but I can't seem to find an example of bib field X is controlled by authority field Y (for LoC thesaurus) in the LC docs. |
| 10:58 |
Dyrcona |
berick: Yeah. I thought that is what you're looking for and I don't see it, either. |
| 10:59 |
Dyrcona |
berick: Mayb this: http://www.loc.gov/marc/authority/ecadcntf.html |
| 11:00 |
Dyrcona |
Eh, maybe not. That appears to just explain what to do when you're making a link in a controlled subfield. |
| 11:03 |
Bmagic |
Dyrcona: years ago, I programmed a "multi" thread perl program that used Encode.pm, however, to get around the multi thread issue, I spawned my seperate instances that all wrote back to their own pid file |
| 11:04 |
Bmagic |
then the master thread periodically checked up on the "threads" by reading that file |
| 11:04 |
Dyrcona |
Bmagic: I'm thinking about either 1) rewriting in Java to use threads or 2) using fork and pipes to communicate. |
| 11:05 |
Dyrcona |
I have a case where I want long-running processes to get information from a master process. |
| 11:05 |
Bmagic |
right, so it can be done in perl |
| 11:05 |
|
rlefaive joined #evergreen |
| 11:06 |
Dyrcona |
I didn't say it couldn't be done in Perl, just not with Perl ithreads on Perl 5.14. (I didn't get that specific before, tbh.) |
| 11:06 |
berick |
abneiman: thanks, but I don't think that's gonna answer my questions either |
| 11:06 |
Bmagic |
Dyrcona: You go with your bad self! |
| 11:06 |
Dyrcona |
But, Thread::Queue in Perl seemed like a natural choice for managing data flow. |
| 11:07 |
Dyrcona |
Bmagic: By years ago are we talking prior to Perl 5.8? |
| 11:08 |
Dyrcona |
'Cause everything changed in Perl 5.8 when it comes to threads. |
| 11:08 |
Bmagic |
no, I believe it was on 14.04 |
| 11:08 |
Bmagic |
You can see the code here https://github.com/mcoia/mobius_evergreen/tree/master/bib_extract |
| 11:12 |
|
jihpringle joined #evergreen |
| 11:14 |
Dyrcona |
That's not actually threading...That's a lot of overhead to manage fork/exec. :) |
| 11:32 |
|
bmills joined #evergreen |
| 11:36 |
Bmagic |
Dyrcona: nope's it's not real threading, by design because of the limitation of Encode.pm. This was the solution that I used |
| 11:37 |
Bmagic |
But, it does extract bib records from the database super fast :) |
| 11:37 |
Dyrcona |
Bmagic: Yep. Perls threads like old userland threads and fork a new interpreter, hence the multiple free errors and segmentation faults when you use Encode.pm. |
| 11:37 |
Bmagic |
10 threads each gathering different sections of biblio.record_entry |
| 11:38 |
Dyrcona |
Yeah. I'm going the other direction and have options similar to yours. But, not sure, I might just do it in Java. |
| 11:40 |
berick |
say what you will about Java, the threading support is excellent |
| 11:41 |
Dyrcona |
Indeed! |
| 11:41 |
Bmagic |
Java has a special place in my heart. I wrote some of my first programs with it |
| 11:41 |
Bmagic |
oracle-- # laying ruin to pure sweet coffee |
| 11:41 |
berick |
:) |
| 11:42 |
Dyrcona |
oracle-- # Just because...Oracle. |
| 11:42 |
berick |
java's a fun place to visit |
| 11:42 |
Dyrcona |
Yeah, it is, but it can brutal if you stay there too long. |
| 11:42 |
Bmagic |
qbasic++ |
| 11:42 |
Dyrcona |
Fortunately, I use Perl to write the more tedious bits for me. :) |
| 11:44 |
Dyrcona |
Perl is now my favorite editor after last night's one-liner that I wrote for something that I'm doing on my own: for (/\W?(\w+)(\W*)/g) { print ucfirst lc $_ } |
| 11:44 |
Dyrcona |
That would have been murder in sed. |
| 11:45 |
abneiman |
berick: Yeah, I misunderstood what you were asking. One can infer that Authority field 100 will control Bib fields 100/600/700; Auth 130 will control Bib fields 130/730/830; etc. -- but I'm also not finding something that explicitly lays that out. |
| 11:46 |
Bmagic |
anyone remember virtual pimp? http://www.petesqbsite.com/sections/express/issue3/virtualp.bas |
| 11:46 |
Bmagic |
qbasic++ |
| 11:52 |
berick |
abneiman: on that note, any idea why in EG the authority control set for bib field 600 (for example) is controlled by auth fields 100,180,181,182,185 ? |
| 11:52 |
berick |
the linking script only looks at auth 100 |
| 11:52 |
berick |
trying to understand the relationship between the two |
| 11:55 |
abneiman |
berick: Auth 180,181,182,185 control subdivisions -- in MARC Bib they would correspond to 6xx subfields x, z, y, and v respectively |
| 11:56 |
|
brahmina joined #evergreen |
| 11:57 |
berick |
abneiman: i'm confused by the fact that a specific subfield, say 600z, appears to be controlled by 5 different authority fields. 100z, 180z, 181z, ... i must be misinterpreting something |
| 11:59 |
berick |
or it's context-specific and I don't yet understand the context |
| 12:17 |
|
jyorio joined #evergreen |
| 12:18 |
|
barbara joined #evergreen |
| 12:29 |
|
jwoodard joined #evergreen |
| 12:33 |
abneiman |
berick: I can see all of them playing a role, but I've never done high-level auth work so I'm not sure what all of the associations there are. I know that for the 18x auth fields there are restrictions on when the x/z/y/v subfields can be added and that subdiv headings get wonky. |
| 12:33 |
abneiman |
Relatively simple example: You can have the established heading -- "651 (151) $a France $x History $y 18th century", which is its own thing as a whole (https://lccn.loc.gov/sh85051305) but also contains pieces "18th century" (Auth field 182, https://lccn.loc.gov/sh2002012474), "History" (Auth field 150, https://lccn.loc.gov/sh85061212), "History -- 18th century" (Auth field 180 with subfield y, https://lccn.loc.gov/sh2002006124), "France -- History |
| 12:33 |
abneiman |
(Auth field 151 with subfield x, https://lccn.loc.gov/sh85051256). |
| 12:34 |
abneiman |
And to FURTHER complicate matters, that whole bit can be put under another heading i.e. 650 (150) $a Architecture $z France $x History $y 18th century (https://lccn.loc.gov/sh2009115453) |
| 12:34 |
abneiman |
Moral of the story is authorities are hard to get a handle on. |
| 12:35 |
berick |
abneiman++ thanks, this gives me something to chew on |
| 12:35 |
abneiman |
np :) it was a fun little bit of digging |
| 12:41 |
berick |
ok, so i take from this the bib 651 is controlled by the auth 151, and the auth 151 in turn is controlled by the various related authority records containing 18X tags |
| 12:42 |
berick |
roughly speaking |
| 12:43 |
berick |
for the purposes of the bib field control, we don't need to concern ourselves with the 18x tags, because that part of the logic (keeping the authority records themselves under control) is handled elsewhere. |
| 12:54 |
abneiman |
berick: that sounds like it should be right, but that's where my knowlege breaks down |
| 12:55 |
jeff |
``As you can see, individual libraries are the direct beneficiaries of all of this MARC 21 standards work. Without it, libraries would not be able to share authority records with ease and accuracy.'' |
| 12:56 |
berick |
abneiman: I'll take it :) it's a good start, anyway |
| 12:59 |
* Dyrcona |
tries to figure out if a fund transfer can be undone in the database. |
| 13:38 |
Dyrcona |
It looks like I can just delete the acq.fund_transfer entries... |
| 13:40 |
Dyrcona |
Looks like I need to delete the corresponding acq.fund_allocation entries, too. |
| 13:43 |
Dyrcona |
And, I should decrement the amounts in fud_allocation_total? |
| 13:43 |
Dyrcona |
:) |
| 13:43 |
Dyrcona |
fund... |
| 13:44 |
Dyrcona |
Oh, this is getting messy.... |
| 13:46 |
jihpringle |
Dyrcona was it a transfer from a funding source to a fund or between funds? |
| 13:47 |
csharp |
Dyrcona: everything in acq is this messy :-/ |
| 13:49 |
Dyrcona |
jihpringle: It was between funds I'm told. I found the acq.fund_transfer entries. |
| 13:52 |
|
jihpringle_ joined #evergreen |
| 13:53 |
Dyrcona |
:) |
| 13:53 |
Dyrcona |
jihpringle: It was between funds. |
| 13:53 |
jihpringle |
Drycona: we delete transfers between the funding sources and funds for our libraries but tell them they have to do a second transfer to fix issues between funds since it's so messy |
| 13:55 |
Dyrcona |
Well, this doesn't look too bad, yet. ;) |
| 13:55 |
jihpringle |
good luck :) |
| 13:55 |
Dyrcona |
I'll probably have to mess with funding_source_balance, too.. |
| 13:55 |
jihpringle |
if you figure out all the tables that have to be adjusted we'd be interested to know |
| 13:56 |
Dyrcona |
I should just tell them too bad, and be more careful next time. :) |
| 13:56 |
jihpringle |
that's what we ended up doing |
| 13:57 |
jihpringle |
since they can do another transfer in the staff client |
| 13:58 |
Dyrcona |
Ah... The source fund is closed, so they can't transfer back. |
| 13:59 |
jeff |
musing on a few things from earlier today (both here and elsewhere), it's sometimes the simplest questions that uncover the complexity of a topic or standard. like how a question of "is there a widely available list of all Dewey Decimal Classification numbers?" quickly leads to subdivisions and the discovery of oddities like the largest (currently known) valid DDC number of 331.890410263362014098133, etc. |
| 14:00 |
Dyrcona |
jeff: Technically, 332.0 is larger than that number. :P |
| 14:00 |
jeff |
best thing about a large palindrome? you only have to remember half of it. |
| 14:01 |
jihpringle |
Drycona: they should be able to switch the fund back to Active, transfer the money, and then set the fund back to inactive (in the funds interface) |
| 14:01 |
jeff |
Dyrcona: s/larg/long/ :P |
| 14:02 |
Dyrcona |
jihpringle: It was last year's fund and fiscal year has been closed. |
| 14:02 |
Dyrcona |
jeff: :P I knew that..... just yanking your chain. |
| 14:03 |
Dyrcona |
Anyway, I've got another pointless question to answer: Doe is pay lost fees or fines first? I should say, "Does it really matter?" |
| 14:03 |
Dyrcona |
With typing like that, I could ruin the database. :) |
| 14:03 |
jeff |
"Doe is pay lost fees or fines first?"? |
| 14:04 |
jeff |
remember: late doe season permits are only valid on private property. |
| 14:04 |
jwoodard |
4 more days till Christmas and my Director wants an Inventory by closing tomorrow...... |
| 14:04 |
jwoodard |
challenge accepted! |
| 14:06 |
jihpringle |
Drycona: if year end close out caused the fund transfer issue (rather than staff) you may have fallen victim to https://bugs.launchpad.net/evergreen/+bug/1478712 in which case it's messier and involves multiple libraries |
| 14:06 |
Dyrcona |
jeff: Ha! |
| 14:06 |
pinesol_green |
Launchpad bug 1478712 in Evergreen "ACQ: Fiscal Year Close-out operation does not check org unit" [Undecided,New] |
| 14:07 |
Dyrcona |
jihpringle: I don't think close out caused the transfer. They mistakenly transferred from the closed fund. Apparently, it lets you do that. |
| 14:09 |
jeff |
Dyrcona: what were you trying to say with your typo'd line? |
| 14:09 |
Dyrcona |
They wanna know if SIP pays lost items or overdues first. |
| 14:10 |
jeff |
ah. |
| 14:10 |
jeff |
"they"? |
| 14:10 |
Dyrcona |
The answer is, "It pays bills in whatever order they come out of the database, so mostly oldest to newest, depending on the state of the tables....basically random order." |
| 14:11 |
Dyrcona |
They --- people I work with/for. |
| 14:11 |
jeff |
got it. |
| 14:11 |
jeff |
wasn't sure if i was missing context that was available elsewhere (looked at list). |
| 14:11 |
Dyrcona |
Nah, I'm just playing pinball today, like most Wednesdays. |
| 14:12 |
jeff |
what is their reason for asking, and/or their preference? |
| 14:15 |
Dyrcona |
Well, it's complicated and has to do with Evergreen SIP not supporting fine item details properly. |
| 14:16 |
jeff |
i'll take some blame for that. |
| 14:16 |
Dyrcona |
It is coming up because you can't pay a specific bill via Evergreen SIP and any existing self check. |
| 14:16 |
Dyrcona |
Heh. |
| 14:16 |
Dyrcona |
It's on our RADAR to fix it, soonish. |
| 14:16 |
Dyrcona |
I don't think it would be very difficult the required info is there. |
| 14:17 |
jeff |
i tried, but once the vendor making the spec stated that they had no way to handle the spec and stated that they would prefer unformatted text, it was a bit of a losing battle / argument to spend more time on it, especially since i had nothing to then test with :P |
| 14:17 |
Dyrcona |
Just a matter of do you prefer the 3M format or the Envisionware format. |
| 14:17 |
* Dyrcona |
sympathizes. :) |
| 14:21 |
Dyrcona |
OK. Back to acq... I think I'll peruse the fund transfer code to see what it looks like I need to do. |
| 14:23 |
miker |
berick: aiui, authority 18x does not control other authorities, they control bibs. they're for when a pre-composed heading with the subdivision doesn't already exist. let's you build a bib heading from a 150 and a 18x. or, that's how it's designed to work today. |
| 14:23 |
Dyrcona |
See, simple. :) |
| 14:23 |
miker |
heh |
| 14:24 |
berick |
miker: ok, i was wondering about that.. so it's there in case the 1xx authority record has not yet caught up |
| 14:24 |
miker |
now, they can control other authorities, too |
| 14:25 |
miker |
auth-auth linking |
| 14:25 |
berick |
miker: right, ok. and we don't link bibs to 18x auths |
| 14:25 |
berick |
we just use the 18x data for auth propagation? |
| 14:25 |
berick |
(to bibs) |
| 14:25 |
miker |
well, you could... by hand |
| 14:26 |
miker |
a cataloger could add a $0 |
| 14:26 |
miker |
but, right. we don't attempt that by machine today |
| 14:27 |
berick |
now if a cataloger were to do that, wouldn't it require the bib field in question to link to multiple auth records? a 1xx link for the main heading, plus then 18x link ? |
| 14:27 |
miker |
fwiw, I don't recall ever seeing an in-use 18x in the wild in an actual ILS |
| 14:28 |
berick |
ok, yea, that last question was mostly just me being curious |
| 14:28 |
Dyrcona |
I know this'll go over like a lead zeppelin, but anyway.... scottmk++ # For comments. |
| 14:28 |
miker |
yes, that's what that would mean. or, a "local" uncontrolled main heading and a controlled subdivision |
| 14:29 |
miker |
Dyrcona: seconded |
| 14:29 |
berick |
miker++ thanks! |
| 14:29 |
berick |
@praise scottmk |
| 14:29 |
* pinesol_green |
scottmk is the hardest working person in #evergreen. |
| 14:30 |
berick |
still! |
| 14:31 |
* Dyrcona |
thought he left under a cloud..... |
| 14:31 |
Dyrcona |
Anyway, good comments on acq.transfer_fund(). |
| 14:52 |
Dyrcona |
So, it looks like the easiest thing would be to do what jihpringle suggested and just transfer the money back. |
| 15:11 |
Dyrcona |
Awesome sauce! |
| 15:12 |
Dyrcona |
I have a test db with a dump from last week loaded and I found a similar transfer from an inactive fund to an active one that I can try this out on. |
| 15:26 |
|
bmills joined #evergreen |
| 15:41 |
rjackson_isl |
gotta love circs with due dates manually entered for beginning of 2016 and items getting marked Lost with max fines accrued the night of the circ :( |
| 15:44 |
Dyrcona |
:) |
| 15:45 |
rjackson_isl |
can I get an Amen?! |
| 16:01 |
JBoyer |
Dyrcona, Am I correct in remembering that you have a script that can import records from a file and replace existing bre.marc based on the 901c in the modified records? |
| 16:01 |
JBoyer |
"modified" being the records in the file. |
| 16:03 |
Dyrcona |
JBoyer: You are mostly correct, yes. |
| 16:03 |
Dyrcona |
Just a second and I'll post the git URL. |
| 16:04 |
Dyrcona |
git://git.mvlcstaff.org/jason/backstage.git |
| 16:04 |
JBoyer |
Thanks. I wanted to load these bibs a while ago and it seems I can take something mostly correct and adjust it much faster than I can start from an empty file and build the whole thing. :/ |
| 16:05 |
Dyrcona |
Yep. |
| 16:06 |
jeff |
today's amusing string of text on a screen: CLIFFORD THE BIG RED ARTIST NOT PROVIDED |
| 16:06 |
Dyrcona |
If that git server ever shuts down, I'll probably move that to github. |
| 16:06 |
JBoyer |
I knew Dali liked dogs. |
| 16:06 |
Dyrcona |
heh |
| 16:07 |
JBoyer |
Dyrcona, at the risk of bringing it to anyone's attention, if you or tsbere don't turn it off, will anyone else even know it's there? |
| 16:07 |
jeff |
also, "THAT IS NOT A GOOD WILLEMS, MO" |
| 16:08 |
Dyrcona |
JBoyer: I've advertised it to the community a few times, but no one seems to notice. |
| 16:08 |
Dyrcona |
I did move a couple of things from there to github when I left MVLC. |
| 16:09 |
JBoyer |
I meant people that could potentially shut it down. :) And I also apparently keep forgetting about it. I knew if you had what I was talking about it would be for Backstage. |
| 16:13 |
Dyrcona |
Ah... Yeah, I think they do know. |
| 16:22 |
Dyrcona |
JBoyer: I've got a fun, but slow, one for mergin 856s into existing records or creating new ones that I wrote for C/W MARS. |
| 16:23 |
Dyrcona |
That's actually what I've been trying to get working with threads and grumbling about with Bmagic. ;) |
| 16:23 |
Dyrcona |
It's not shared publicly, yet, though. |
| 16:28 |
Dyrcona |
I love documentation lines like this: It is probably not the command you want to use; see "save" above. |
| 16:29 |
Bmagic |
agreed, those are sweet |
| 16:34 |
Dyrcona |
jihpringle++ |
| 16:34 |
Dyrcona |
jihpringle: We told them to do what you suggested and it worked. I also know how to reverse it in the database, now. :) |
| 16:35 |
Dyrcona |
"There are not the commands you are looking for." *hand wave* |
| 16:48 |
Dyrcona |
Another gem: "However, a file generated in this manner will have some items that should not be preseeded, and the example file is a better starting place for most users." |
| 16:49 |
Dyrcona |
You just want to say, "So why tell me about it, then?" |
| 16:49 |
Dyrcona |
'Nix guys..... ;) |
| 16:51 |
Dyrcona |
Well, I'm heading home. TTYT! |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:08 |
|
bmills joined #evergreen |
| 17:13 |
pinesol_green |
[evergreen|Galen Charlton] LP#1651808: avoid a class of intermittent search failures - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f67b07b> |
| 17:19 |
|
jvwoolf left #evergreen |
| 17:37 |
|
bmills joined #evergreen |
| 17:44 |
jeff |
i really shouldn't be thinking about the ability to merge copies. |
| 17:57 |
|
_adb left #evergreen |
| 18:03 |
|
NawJO joined #evergreen |
| 18:54 |
|
bmills joined #evergreen |
| 18:57 |
|
cbush06 joined #evergreen |
| 19:40 |
|
bmills joined #evergreen |
| 20:07 |
|
Christineb joined #evergreen |
