| Time |
Nick |
Message |
| 00:31 |
|
bbqben joined #evergreen |
| 04:46 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 08:00 |
|
mrpeters joined #evergreen |
| 08:02 |
|
Dyrcona joined #evergreen |
| 08:12 |
|
rjackson_isl joined #evergreen |
| 08:21 |
Dyrcona |
Well, that's funky. |
| 08:22 |
Dyrcona |
I rm'd a program from my bindir. |
| 08:22 |
Dyrcona |
Then linked a different program in its place. |
| 08:22 |
Dyrcona |
When I run the command, I get the output from the one that I deleted. |
| 08:22 |
Dyrcona |
Something must be cached. |
| 08:23 |
|
akilsdonk joined #evergreen |
| 08:24 |
|
ericar joined #evergreen |
| 08:25 |
Dyrcona |
On an unrelated note, I wish more vendors would accept UTF-8 in MARC records. |
| 08:26 |
Dyrcona |
'Cause I just should not be seeing messages like this in my email: no mapping found at position 0 in ⓟ2015. at /usr/share/perl5/MARC/Charset.pm line 384. |
| 08:27 |
Dyrcona |
Hrm.... That funkiness continues after a reboot! |
| 08:28 |
|
Newziky joined #evergreen |
| 08:30 |
Dyrcona |
Well, Google is no help..... I suspect this has something to do with python caching a compiled version somewhere. |
| 08:33 |
Dyrcona |
Whoa! |
| 08:33 |
Dyrcona |
Not what I expected at all. How did that happen? |
| 08:34 |
phasefx_ |
path? |
| 08:34 |
Dyrcona |
Nope. Silly me. |
| 08:35 |
Dyrcona |
So, when I copied the Python script into place, I named it the same as an existing link. |
| 08:35 |
Dyrcona |
It replaced the original executable. |
| 08:35 |
Dyrcona |
I didn't really think about the link existing at the time. |
| 08:37 |
Dyrcona |
A git reset fixed my problem, though. :) |
| 08:37 |
Dyrcona |
git++ |
| 08:38 |
|
graced joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 08:41 |
Dyrcona |
For practice, I'm working on reimplementing a Perl program that I wrote for Evergreen in Python. |
| 08:51 |
Dyrcona |
Heh. Was going to add a check to a program to only upload a file if it's size was greater than 0 bytes. |
| 08:51 |
Dyrcona |
Apparently, I did that on June 14 last year. |
| 09:00 |
|
remingtron joined #evergreen |
| 09:05 |
|
Stompro joined #evergreen |
| 09:12 |
jeff |
Dyrcona: symlinks are sneaky like that. lots of fun security vulns made use of them in a similar fashion. |
| 09:16 |
Dyrcona |
Yep. Helps to be vigilant, and when I copied the file from my laptop to the server, I had a sneaky suspicion I was doing something wrong. |
| 09:29 |
|
yboston joined #evergreen |
| 10:28 |
mmorgan |
Duration rule question: Does anyone/everyone make use of short/normal/long loan durations? We do, but I'm wondering if it's more trouble than it's worth. |
| 10:29 |
gsams |
mmorgan: No one in my consortium uses them that I am aware of, we have them all set to the same value to avoid issues. |
| 10:30 |
Dyrcona |
mmorgan: We set them all to be the same and named our duration rules for the duration and number of renewals, i.e. 21_day_2_renew. |
| 10:30 |
gsams |
Dyrcona++ #same deal here |
| 10:30 |
Dyrcona |
gsams++ |
| 10:30 |
Dyrcona |
It's Friday....It's karma party time! ;) |
| 10:31 |
mmorgan |
:-D |
| 10:32 |
Dyrcona |
We actually had plans at one point to name circ modifiers for the rules that apply to the copy, but that got shelved while more important things get done. |
| 10:32 |
mmorgan |
I'm wondering if anybody DOES have a good use case for the different durations. |
| 10:33 |
Dyrcona |
csharp and pines presumably would. |
| 10:33 |
mmorgan |
I can think of one that applies here: New items can have a shorter loan period initially, then a longer loan period when they're no longer popular. |
| 10:33 |
gsams |
I can't say that I can figure one out for any of our libraries, that wouldn't be covered by some other option more easily. |
| 10:34 |
mmorgan |
Our circ modifiers are format based. book, dvd, etc. |
| 10:35 |
Dyrcona |
Our circ modifiers are modifiers: hot, bestseller, etc. We use MARC fields for DVDs, etc. |
| 10:35 |
* Dyrcona |
is kinda masochistic like that. ;) |
| 10:35 |
mmorgan |
No MARC fields here, just circ modifiers. |
| 10:36 |
Dyrcona |
What we've discussed with rule-based circ mods is encoding the loan duration, renewals, and holdability in the name somehow. |
| 10:36 |
Dyrcona |
Something like 3wk-2r-hold or whatever. |
| 10:37 |
Dyrcona |
Then, there's no question what happens. |
| 10:37 |
gsams |
Isn't there an option in circ policies to base the policy on the age of the item? |
| 10:37 |
Dyrcona |
gsams: There's age hold protection for one thing. |
| 10:38 |
mmorgan |
Dyrcona: So people don't get circ stats based on circ modifiers? |
| 10:38 |
gsams |
Dyrcona: Sure, but isn't there an Item Age < option in the circ policies table? |
| 10:38 |
Dyrcona |
mmorgan: Nope, we have a whole legacy set of stat_cats we call "collection" that we've been using since GEAC, I think. |
| 10:38 |
mmorgan |
gsams: Yeah. That's there, but it wouldn't apply in our case, since we use acquisitions. |
| 10:39 |
Dyrcona |
gsams: Yes, there is, but we never use it. |
| 10:40 |
gsams |
mmorgan: Yeah, that would certainly make that a less attractive option for new items then. |
| 10:40 |
Dyrcona |
We use the aged hold protection to try and keep new things at home for a month or so before it goes out and fills holds. |
| 10:40 |
mmorgan |
Active date is what's important to us. I'm assuming that item age is based on create date, though I haven't looked to be sure ;-) |
| 10:40 |
* csharp |
scrolls up |
| 10:42 |
gsams |
I'm actually a bit surprised there isn't either an active date option or YAOUS for it. That'd be a neat feature for those that use Acq. |
| 10:43 |
Dyrcona |
Well, age hold protection is based on active date. |
| 10:43 |
Dyrcona |
Not sure about the field in circ_matrix_matchpoint |
| 10:44 |
csharp |
mmorgan: we use normal/short/long durations to allow libraries some local choice when they're cataloging copies - our policies are very strictly centralized |
| 10:44 |
mmorgan |
Active date for age based hold protection is a YAOUS |
| 10:44 |
csharp |
(for certain items, not all) |
| 10:44 |
Dyrcona |
mmorgan: Right. We have it set to use active date, so I just assume... ;) |
| 10:45 |
gsams |
csharp: I had a feeling that would be the case there. I imagine it would be a nightterror otherwise. |
| 10:45 |
gsams |
because I think nightmare would be an understatement... |
| 10:45 |
mmorgan |
Ah. OK, it does make sense for central circ policies. Our circ policies are pretty custom library by library. |
| 10:45 |
Dyrcona |
heh |
| 10:46 |
Dyrcona |
Ah, Massachusetts.... |
| 10:46 |
Dyrcona |
;) |
| 10:46 |
mmorgan |
:-D |
| 10:46 |
gsams |
mmorgan: we have things setup library by library here, but it's a small group without a real central organization. |
| 10:47 |
Dyrcona |
We have committees that make policy recommendations, but members can legally do whatever they want. |
| 10:47 |
Dyrcona |
Most members do follow the recommendations on the main things: DVDs, Books, etc. |
| 10:47 |
gsams |
We have a policies and procedures committee, but they've never once bothered to try for something like that. |
| 10:48 |
gsams |
Though I could bug them to consider making recommendations at least, that'd be something to think about. |
| 10:48 |
Dyrcona |
It's fun configuring rules for Nooks, iPads, et al. |
| 10:49 |
gsams |
Yeah, we haven't made the step yet. |
| 10:50 |
Dyrcona |
The parameters are all over the place. I don't think our members even talk to each other much when it comes to the parameters that they use for these things. |
| 10:51 |
gsams |
Since we have such a small group we tend to talk about the smallest things, but I can't think of a time that anyone has discussed lending rules for suggestions. |
| 10:52 |
Dyrcona |
Well, every group has its own dynamics. |
| 10:52 |
gsams |
Indeed! We have another consortium close by that has a story about how they came to an agreement on lending policies. |
| 10:53 |
mmorgan |
Many of our libraries differ on very basic policies, like how long a book circulates. |
| 10:53 |
gsams |
It involved renting a hotel room and stuffing them all in there and locking the door. |
| 10:54 |
gsams |
Could have been a meeting room somewhere, the story tends to change. |
| 10:54 |
mmorgan |
gsams: That's one way to get something done! ;-) |
| 10:54 |
Dyrcona |
Yeah. |
| 10:54 |
Dyrcona |
I imagine a hotel meeting room. |
| 10:56 |
csharp |
gsams: that's the PINES story - not sure if we're the consortium you're talking about though ;-) |
| 10:58 |
gsams |
csharp: Ah! That is probably the story I am thinking of! I should've known better! |
| 10:59 |
gsams |
Though the other consortium close to us does have a centrally controlling authority that did insist on as close to unified policies as possible, so it could have been an inspired story. |
| 10:59 |
csharp |
the 2 major principles that came out of that that ease consortial management were 1) a consistent user experience across PINES as far as circ policies, fine rates, etc. go and 2) they didn't want to transport nickels and dimes across system lines, so fines can be paid at any location without the need for "settling up" (though lost items are paid up each month to the item owning library) |
| 11:01 |
gsams |
We found after a year of working as a group that the fine exchange was so small as to be nearly flat across the board. It took us a year to get to a point where fines even could be exchanged at all and it wasn't worth the paper so we just tossed it. |
| 11:01 |
* gmcharlt |
is now hoping for archival pictures of the old PINES nickel-and-dime trucks ;) |
| 11:03 |
gsams |
gmcharlt++ |
| 11:04 |
Dyrcona |
I gave up understanding our rules, except that lost item fees are supposed to go to the copy owning library. |
| 11:13 |
|
dkyle2 joined #evergreen |
| 11:14 |
|
_bott_1 joined #evergreen |
| 11:18 |
mmorgan |
Fines can be accepted at any of our libraries. Lost item fees go to the owning library. |
| 11:22 |
mmorgan |
Thanks for the input all. I may consider un-doing different durations in each rule. Summer project, maybe. |
| 11:23 |
|
_bott_ joined #evergreen |
| 11:24 |
|
dkyle joined #evergreen |
| 11:28 |
|
drigeny joined #evergreen |
| 11:28 |
|
BigRig joined #evergreen |
| 11:49 |
|
dbwells joined #evergreen |
| 12:55 |
|
ericar_ joined #evergreen |
| 13:48 |
|
ericar_ joined #evergreen |
| 13:55 |
Stompro |
Does anyone have Evergreen/OpenSRF Zabbix templates developed already? |
| 13:55 |
Stompro |
I'm just working on setting some up, maybe someone has already done the work. |
| 13:55 |
bshum |
I think the Missouri folks talked about zabbix once. Bmagic or hopkinsju |
| 13:59 |
Stompro |
From the IRC logs it looks like it was hopkinsju... I'll send him an email, thanks. |
| 14:27 |
pinesol_green |
[opensrf|Dan Scott] LP#1409055 Support specific protocols for OpenSRF gateway requests - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=cc1f6ee> |
| 14:41 |
* dbs |
sighs |
| 14:41 |
dbs |
so, I tried using a "git merge" to merge the branch from OpenSRF master that contained berick's signoff of my one commit to OpenSRF rel_2_4 |
| 14:42 |
* jeff |
looks |
| 14:42 |
dbs |
And it looks like it pulled in 19 commits? |
| 14:42 |
dbs |
from a8ea7468ed1 |
| 14:42 |
pinesol_green |
[opensrf|Galen Charlton] LP#1436047: make srfsh --safe act as if "! command" doesn't exist - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a8ea746> |
| 14:44 |
jeff |
dbs: this is in your local working copy, not something you've pushed? |
| 14:44 |
dbs |
No, it's pushed now |
| 14:45 |
dbs |
530220a85 |
| 14:45 |
pinesol_green |
[opensrf|Dan Scott] Merge remote-tracking branch 'working/user/berick/lp1409055-python-https-via-dbs' into https_is_good_24 - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=530220a> |
| 14:45 |
jeff |
oh, not master -- got it. sorry. |
| 14:45 |
berick |
yeah, you have to cherry-pick for back-ports IIRC |
| 14:45 |
dbs |
In the past, I would have used cherry-pick but thought we were trying to use merge |
| 14:46 |
dbs |
So I guess "use git merge for master, cherry-pick for backports" is the explicit direction if we go that route? |
| 14:46 |
jeff |
dbs: we've not adopted that yet because i've neither tried some of these things nor proposed it yet :-) |
| 14:46 |
jeff |
dbs: your experiences and feedback are being absorbed as we speak! :-) |
| 14:46 |
dbs |
I'll revert the merge and cherry-pick the commit in question. |
| 14:46 |
jeff |
dbs++ thanks! |
| 14:49 |
jeff |
i can't say i'm terribly opposed to a force-push to rel_2_4 in this case, but others may object -- or even the git server perms may. |
| 14:51 |
gmcharlt |
no, please don't force push |
| 14:51 |
jeff |
see "others may object" :-) |
| 14:51 |
|
Canaimero-34 joined #evergreen |
| 14:51 |
gmcharlt |
reverts are not a banner of shame |
| 14:51 |
|
Canaimero-34 left #evergreen |
| 14:52 |
dbs |
reverts are a learning exercise (sigh) |
| 14:52 |
gmcharlt |
painful at times... but yes :) |
| 14:53 |
* dbs |
is learning a lot from ftp://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt |
| 14:55 |
|
linuxhiker joined #evergreen |
| 14:55 |
kmlussier |
Hello #evergreen. Happy Friday! |
| 14:55 |
jeff |
on the subject of merge vs cherry-pick, the following is a bit of dissenting opinion i've bookmarked for later reading: http://endoflineblog.com/gitflow-considered-harmful -- it's from earlier last month but has been generating comments on hn today. |
| 14:57 |
dbs |
I think it's all sorted out now |
| 14:57 |
Dyrcona |
Hello, kmlussier! |
| 14:58 |
dbs |
git revert 530220a8 -m 1; git cherry-pick working/user/berick/lp1409055-python-https-via-dbs; and pushed to rel_2_4 |
| 14:58 |
pinesol_green |
[opensrf|Dan Scott] Merge remote-tracking branch 'working/user/berick/lp1409055-python-https-via-dbs' into https_is_good_24 - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=530220a> |
| 14:58 |
Dyrcona |
jeff: read that one the other day when it was shared in G+ git community. |
| 14:58 |
jeff |
Dyrcona: i'll have to seek out that discussion as well. |
| 14:59 |
Dyrcona |
I'll do whatever the community I'm working in does. |
| 14:59 |
jeff |
i liked this soundbite from some of the hn conversation today, in defense of "messy" timelines -- "I prefer my code to be clean and my history to be correct." |
| 15:00 |
Dyrcona |
heh. I prefer it the other way 'round. ;) |
| 15:00 |
* jeff |
laughs |
| 15:00 |
Dyrcona |
kmlussier: My office is packed, except for the stuff I use every day. |
| 15:00 |
Dyrcona |
Only took 1 crate. |
| 15:00 |
jeff |
kmlussier: happy friday! |
| 15:01 |
Dyrcona |
Oh, yeah. MVLC is moving over the 27th to 29th of the month. |
| 15:01 |
Dyrcona |
So, like we'll be down and stuff. ;) |
| 15:01 |
kmlussier |
Dyrcona: I'm not surprised it took only 1 crate. Your office is pretty sparse. |
| 15:02 |
Dyrcona |
Yep. |
| 15:09 |
Dyrcona |
jeff: with cherry-pick versus merge, I guess it matters more if you care about the author date of the original patch or the commit date into the master branch. |
| 15:09 |
Dyrcona |
I mean which you use depends on which matters more to the project. |
| 15:09 |
Dyrcona |
I'm only fluent in English. It's not as good as my Perl. :) |
| 15:20 |
Dyrcona |
Oh, fun! I get to figure out a cstore/json query to find circs that are due today and then how to run it from Python. |
| 15:23 |
berick |
Dyrcona: fyi, there's a 'csedit' (CStoreEditor) class in python |
| 15:23 |
berick |
though, surely, it's not been put through the paces |
| 15:23 |
berick |
:) |
| 15:23 |
Dyrcona |
berick: Cool. |
| 15:23 |
berick |
good luck :) |
| 15:23 |
Dyrcona |
I'm actually leaning toward a pcrud search. |
| 15:24 |
berick |
*nod* |
| 15:24 |
Dyrcona |
berick: For the json query, do I just put the json in as-is? |
| 15:24 |
Dyrcona |
From the only example I can find, it looks like I can do that. |
| 15:26 |
berick |
Dyrcona: yeah, IIRC, JSON looks just like python objects (dicts, arrays, strings) |
| 15:26 |
Dyrcona |
berick: Thanks! That is what I thought. |
| 15:26 |
berick |
so no need to do any translation like you have to do with perl objects => hashes, etc. |
| 15:27 |
Dyrcona |
Think I'll just look up all of wife's circulations as a test. |
| 15:27 |
Dyrcona |
I'd look up mine, but I have nothing checked out at the moment. |
| 15:28 |
Dyrcona |
Do I say None for null? |
| 15:29 |
berick |
yeah |
| 15:29 |
berick |
that bit's different |
| 15:29 |
berick |
from json |
| 15:29 |
berick |
so, some translation :) |
| 15:38 |
Bmagic_ |
Has anyone got the question from their members about making the staff client OPAC search results not* include empty bibs? |
| 15:39 |
Dyrcona |
Bmagic_: No. |
| 15:40 |
mmorgan |
YES. The problem is they show in all scopes, getting in the way of finding what they're looking for. |
| 15:40 |
Dyrcona |
Though sometimes it is asked, "Why?" |
| 15:40 |
csharp |
@quote add < Dyrcona> I'm only fluent in English. It's not as good as my Perl. :) |
| 15:40 |
pinesol_green |
csharp: The operation succeeded. Quote #119 added. |
| 15:40 |
mmorgan |
Our solution is to have as few empty bibs in the db as possible. |
| 15:43 |
Bmagic_ |
mmorgan: ha! We have a tone of electronic bibs which might be part of the complaint, I will have to investigate |
| 15:43 |
Bmagic_ |
Im gonna logout and correct my nick tail |
| 15:43 |
|
Bmagic joined #evergreen |
| 15:45 |
Dyrcona |
Bmagic: You can usually fix your nick by running /nick. |
| 15:45 |
Bmagic |
Oh, I'll have to try that next time |
| 15:46 |
mmorgan |
Bmagic: We use located URIs for electronic bibs. |
| 15:48 |
Bmagic |
mmorgan: we do as well |
| 15:52 |
mmorgan |
Bmagic: we also have the Global Flag "When enabled, Located URIs will provide visiblity behavior identical to copies." set to TRUE. |
| 15:52 |
Dyrcona |
berick: is something like "while not request.complete: data = request.recv() ...." the best way to loop over multiple request responses? |
| 15:55 |
berick |
Dyrcona: that might work. i forget. |
| 15:55 |
berick |
you can also reference srfsh.py |
| 15:55 |
berick |
http://git.evergreen-ils.org/?p=OpenSRF.git;a=blob;f=src/python/srfsh.py;h=a8d65a04af0f0f49beac959371a504609e851b3b;hb=HEAD#l284 |
| 15:55 |
Dyrcona |
It works. I just wondered if there was a better way. |
| 15:56 |
berick |
ah |
| 15:57 |
berick |
srfsh-style is probably overkill for common stuff |
| 15:57 |
Dyrcona |
Yeah, it could be, but it looks pretty robust. |
| 15:57 |
Dyrcona |
I might use something like that if I need something reliable. :) |
| 15:57 |
berick |
yeah |
| 15:58 |
Dyrcona |
Right now, I'm just fiddling around to improve my Python skills. |
| 16:02 |
Dyrcona |
So, could I just drop a dict in for the json query? |
| 16:02 |
Bmagic |
I just discovered that this table has doubles: config.coded_value_map . Anyone else have doubles? select code,count(*) from config.coded_value_map where ctype='vr_format' group by code order by code |
| 16:02 |
Bmagic |
I wonder if it was a DB upgrade script somewhere |
| 16:05 |
berick |
Dyrcona: yes |
| 16:05 |
Dyrcona |
berick: Yeah, I was just testing it. |
| 16:07 |
Dyrcona |
It's gonna be fun when I try to do date_trunc('day', now()) = date_trunc('day', due_date)... I'll probably need to refer to the great page on the wiki. |
| 16:08 |
berick |
Dyrcona: yeah, i always have to scan the code for stuff like that. might be easier to use between |
| 16:11 |
jeff |
(as well as more performant on the postgres side) |
| 16:11 |
jeff |
if there's one thing i picked up from #postgresql it's the advice to avoid queries where you need to cast / transform every value in a column. |
| 16:12 |
Dyrcona |
Well, I could just build a date string with the right time. |
| 16:12 |
jeff |
it can make for more complicated queries in my reports, but when it shaves minutes off the execution time without need for additional indexes, and the report is run somewhat often... :-) |
| 16:13 |
jeff |
slightly verbose, perhaps one more cast than absolutely needed, but... WHERE due_date BETWEEN NOW()::DATE and (NOW()::DATE + '1 day'::INTERVAL)::DATE |
| 16:14 |
jeff |
might need to shave one second off the second argument to BETWEEN to avoid midnight tomorrow. |
| 16:14 |
jeff |
but you get the idea. |
| 16:15 |
Dyrcona |
jeff: Yeah. |
| 16:15 |
Dyrcona |
Heh. I could see building complicated queries in dicts looking just as crazy as it gets in Perl. |
| 16:15 |
Dyrcona |
Maybe crazier. |
| 16:17 |
|
pgwhatever joined #evergreen |
| 16:19 |
Dyrcona |
I like the while True, get the next response, if not response: break flow. |
| 16:21 |
pgwhatever |
im attempting to get the vanilla evergreen DDL and compare it against a customized remote branch, so i cloned as follows: git clone git://git.evergreen-ils.org/Evergreen.git |
| 16:22 |
pgwhatever |
and Now I want to extract the DDL to create the evergreen database. I see most of the DDL is here .../Open-ILS/src/sql/Pg |
| 16:22 |
pgwhatever |
s there some bash script that executes these to build a database? I really dont want to build Evergreen, just grab its ddl and create a database. |
| 16:23 |
pgwhatever |
or can I just create my own bash script to loop through them, each is prepended with a number like 001<name>, 002<name>, so im guessing the numbering indicates the necessary order or execution |
| 16:23 |
pgwhatever |
of execution |
| 16:28 |
Stompro |
pgwhatever, you need to use the eg_db_config script - see http://docs.evergreen-ils.org/2.8/_creating_the_evergreen_database.html If you look at the source to that script you can see how the DDL is processed. |
| 16:28 |
jeff |
pgwhatever: there is a perl script -- take a look at Open-ILS/src/support-scripts/eg_db_config.in |
| 16:29 |
kmlussier |
miker: Have you left your eeevil ways? |
| 16:29 |
* jeff |
looks at that file to see why it's processed by autoconf |
| 16:29 |
miker |
kmlussier: :) ... after all these years, I was finally able to get my nick |
| 16:30 |
kmlussier |
Yay! I've always liked the miker nick. :) |
| 16:30 |
jeff |
miker: congrats! |
| 16:31 |
miker |
it had a tail until yesterday |
| 16:33 |
Dyrcona |
jeff: It's processed by autoconf because it needs paths to configurations that are determined by autocong. |
| 16:35 |
jeff |
amusingly, only the usage / help uses @sysconfdir@ now. :-) |
| 16:36 |
jeff |
and arguably is (can be) wrong, since it really defaults to the output of eg_config --sysconfdir |
| 16:36 |
gmcharlt |
bshum: about? |
| 16:39 |
berick |
miker: whoa! that's been a long time in the making. i'll just assume a drone strike was involved. |
| 16:41 |
miker |
berick: I'll never tell |
| 16:41 |
gmcharlt |
*cough*ninjas*cough* |
| 16:43 |
Bmagic |
When importing MARC with batch import/export can it delete matching records? |
| 16:43 |
jeff |
Bmagic: are you asking for WMA reasons? |
| 16:44 |
Bmagic |
no |
| 16:44 |
jeff |
k. nevermind me, then. |
| 16:46 |
bshum |
gmcharlt: Oh hi |
| 16:46 |
Dyrcona |
Bmagic: Through Vandelay? I don't think so. |
| 16:46 |
gmcharlt |
bshum: woudl I assume correctly that a merge commit in Evergreen master will make pinesol unappy? |
| 16:46 |
Dyrcona |
I write my own scripts to do that. |
| 16:47 |
Bmagic |
Yeah, through Vandelay. What is the routine for mass deleting bibs from a matching MARC file? |
| 16:47 |
bshum |
gmcharlt: Yeah, that's usually when it breaks down. My recommendation is to unload Git |
| 16:47 |
Dyrcona |
Bmagic: AFAIK, there isn't one. |
| 16:47 |
jeff |
the only one i'm aware of is the logic in Dyrcona's Safari load script. |
| 16:47 |
gmcharlt |
nah, I'll just cherry-pick on a Friday afternoon |
| 16:47 |
Bmagic |
Dyrcona: Gotcha |
| 16:47 |
bshum |
But we can test it. |
| 16:48 |
Dyrcona |
Bmagic: As jeff pointed out, my safariload script checks for d in the leader and deletes bibs if found: http://git.mvlcstaff.org/?p=jason/safariload.git;a=summary |
| 16:49 |
Dyrcona |
You might be able to use it as an example/starting point. |
| 16:49 |
Dyrcona |
And, while fiddling with my Python script, I discover that two of my wife's circs from 2011 have xact_finish set but no checkin_scan_time. |
| 16:51 |
Dyrcona |
And, they were migrated that way... |
| 16:51 |
Dyrcona |
@who did MVLC's migration! |
| 16:51 |
pinesol_green |
mrpeters did MVLC's migration. |
| 16:51 |
Dyrcona |
:) |
| 16:51 |
Dyrcona |
@blame Dyrcona |
| 16:51 |
pinesol_green |
Dyrcona: Dyrcona forgot to give the gerbils their chocolate-frosted sugar bombs |
| 16:51 |
Dyrcona |
That he did. |
| 16:52 |
pinesol_green |
[evergreen|Yamil Suarez] LP#1465830: authority linker now ignores $e and $4 in bib name headings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a0ada5b> |
| 16:52 |
jeff |
Dyrcona: checkin_scan_time will be null for older circs. |
| 16:52 |
jeff |
Dyrcona: though i don't recall your go-live date. |
| 16:52 |
Dyrcona |
May 2011. |
| 16:53 |
Dyrcona |
These are from March 2011. |
| 16:53 |
jeff |
ah. |
| 16:53 |
Bmagic |
Dyrcona: I wrote something simliar to maintain overdrive records monthly. I guess we can't put this into the librarians hands |
| 16:53 |
Dyrcona |
Bmagic: A central site cataloger loads our Overdrive records. |
| 16:54 |
Dyrcona |
I automate Safari and most e-book type subscription things, 'cause they change frequently. |
| 16:54 |
Dyrcona |
It's a pain to remember to do the loads manually and a wast of a person's time. |
| 16:54 |
Dyrcona |
Automate the boring stuff. |
| 16:55 |
jeff |
s/boring // |
| 16:57 |
Dyrcona |
heh. |
| 16:58 |
Dyrcona |
Well, that's it for me today. |
| 17:01 |
gsams |
I've got a shelving location that we are splitting into genre's locations |
| 17:01 |
gsams |
So I figured, SQL would be my best way to move all the items to a newly created shelving location |
| 17:02 |
gsams |
except I can't seem to get my update where command to only target the right items |
| 17:03 |
pastebot |
"gsams" at 64.57.241.14 pasted "Update Shelving locations SQL" (9 lines) at http://paste.evergreen-ils.org/74 |
| 17:03 |
gsams |
It should be targetting all of 270 items in that command, but it seems to be targetting 2400 instead |
| 17:04 |
gsams |
It's like it is not counting the not deleted or the call number portions |
| 17:08 |
gsams |
It's actually even more confusing than that even. It changed items in a specific shelving location to the new one, but not just the ones that were reported in that select statement. |
| 17:11 |
mmorgan |
gsams: I think you need a not deleted condition before the "where location in (... " |
| 17:11 |
mmorgan |
Of course, that's on a Friday afternoon brain ;-) |
| 17:12 |
gsams |
heh, that's probably what the problem is for me! That just made me notice that my deleted is for the wrong table... |
| 17:12 |
gsams |
mmorgan++ #you are probably right! |
| 17:13 |
jeff |
gsams: you are selecting all locations of any copies with a call number matching your pattern, then you are changing any copies in those locations to be your location 3819. |
| 17:13 |
jeff |
gsams: this is probably not what you want. |
| 17:16 |
gsams |
jeff: I should be selecting all locations with my call number pattern attached to items owned by my library? |
| 17:17 |
jeff |
gsams: are all of the items you want to change in a certain shelving location right now, or are they all over the place? |
| 17:17 |
gsams |
single shelving location, changing to multiple locations |
| 17:17 |
jeff |
what is the id of the single source shelving location? |
| 17:18 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:18 |
gsams |
It's actually 3819, I don't know why the one I pasted had that for the set, the new one is 4870. |
| 17:19 |
gsams |
since it was based on the call number pattern, I figured singling out the owning library and call number pattern was the best option |
| 17:22 |
|
Newziky left #evergreen |
| 17:25 |
jeff |
gsams: i took your original query and updated it -- does this approach look better? Please don't run this "for real" on live data without appropriate safeguards, etc: https://gist.github.com/jeff/50f2999095e175c49362 |
| 17:25 |
gsams |
jeff: Thankfully, testing it on a backup. |
| 17:26 |
jeff |
gsams: that FROM statement on the UPDATE query is how you do an UPDATE with a JOIN, essentially |
| 17:26 |
mmorgan |
gsams: Again, the Friday afternoon brain, but you could *test* this one too, based on yours... |
| 17:26 |
jeff |
and what would be your ON becomes just another part of the WHERE clause |
| 17:26 |
pastebot |
"mmorgan" at 64.57.241.14 pasted "Possible query" (9 lines) at http://paste.evergreen-ils.org/75 |
| 17:28 |
gsams |
mmorgan: Ah. Yes now I understand what dumb I was actually perpetrating. |
| 17:28 |
gsams |
ha |
| 17:28 |
gsams |
mmorgan++ |
| 17:28 |
gsams |
jeff++ |
| 17:29 |
gsams |
Yes I believe either of these would sufficiently make the right change as it were. |
| 17:29 |
* mmorgan |
would always defer to jeff's postgres skills, though. |
| 17:30 |
jeff |
mmorgan: that looks reasonable also. if your subselect also limited to NOT acp.deleted and you account for the updated source/dest location criteria that gsams provided, i think yours and mine are functionally the same at first glance. |
| 17:30 |
jeff |
(i added the NOT acp.deleted and dropped the join of asset.copy_location, etc) |
| 17:30 |
jeff |
mmorgan: you stayed closer to gsams' original query, which was probably more useful in demonstrating the difference / issue. :-) |
| 17:31 |
gsams |
jeff++ #I was trying to put that exactly to words about demonstrating the issue |
| 17:32 |
mmorgan |
I'm more comfortable using IN for stuff like this, but I also know that the join approach can be much more efficient. |
| 17:34 |
gsams |
I had originally been selecting more fields and used the copy location table during that and forgotten to remove it, which was a bit silly. |
| 17:34 |
* mmorgan |
needs to call it a week. Good Weekend All! |
| 17:34 |
|
mmorgan left #evergreen |
| 17:36 |
gsams |
mmorgan: havea good weekend! thanks again! |
| 17:41 |
pgwhatever |
hmmm i see eg_db_config.in not eg_db_config.pl when I donload the evergreen repo |
| 17:42 |
pgwhatever |
dag wish there were some easy way to get the vanilla evergreen ddl |
| 18:05 |
|
Newziky1 joined #evergreen |
| 18:09 |
|
finnx joined #evergreen |
| 19:03 |
|
ohiojoe joined #evergreen |
| 19:20 |
|
hopkinsju joined #evergreen |
| 19:26 |
|
_bott_ joined #evergreen |
