| Time |
Nick |
Message |
| 00:35 |
|
jihpringle joined #evergreen |
| 04:02 |
|
gsams joined #evergreen |
| 05:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:22 |
|
graced joined #evergreen |
| 07:27 |
|
jboyer-isl joined #evergreen |
| 07:50 |
|
rjackson_isl joined #evergreen |
| 07:56 |
|
ericar joined #evergreen |
| 08:21 |
|
jboyer-isl joined #evergreen |
| 08:22 |
|
Callender_ joined #evergreen |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:48 |
remingtron |
Anyone awake who's familiar with EDI in Evergreen? |
| 08:48 |
remingtron |
I'd like someone to review this Docs branch |
| 08:49 |
remingtron |
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/rsteed/docs_edi_sandberg |
| 08:50 |
remingtron |
I merged some fairly old improvements from sandbergja (sorry it took so long!) into the current docs, and want to make sure it's still accurate |
| 08:57 |
bshum |
remingtron: quick review, didn't see anything off |
| 08:57 |
bshum |
Looks okay to merge to me. |
| 08:59 |
bshum |
Yep, all looks okay. |
| 09:00 |
bshum |
Good tips and notes as far as I'm concerned and matches my general experience setting up EDI. |
| 09:01 |
remingtron |
bshum: cool, thanks for reviewing |
| 09:04 |
|
Mr_Carter joined #evergreen |
| 09:04 |
|
montgoc1 joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:29 |
|
maryj joined #evergreen |
| 09:39 |
|
yboston joined #evergreen |
| 09:43 |
|
collum joined #evergreen |
| 09:45 |
|
ericar_ joined #evergreen |
| 09:58 |
pinesol_green |
[evergreen|Jane Sandberg] Docs: General improvements to EDI docs - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6bb8ea5> |
| 10:02 |
|
jwoodard joined #evergreen |
| 10:09 |
|
mrpeters joined #evergreen |
| 10:19 |
bshum |
"Blake, conducting magic" |
| 10:19 |
bshum |
Bmagic++ # awesome email sig |
| 10:19 |
Bmagic |
lol! Thanks! |
| 10:19 |
kmlussier |
Ha ha. It suits you Bmagic! |
| 10:19 |
kmlussier |
Bmagic++ |
| 10:20 |
Bmagic |
haha! |
| 10:20 |
Bmagic |
I have to be careful, sometimes people really want me to poof their issues away! |
| 10:27 |
csharp |
@fix |
| 10:27 |
pinesol_green |
csharp: You keep using that word. I do not think it means what you think it means. |
| 10:35 |
bshum |
Hmm |
| 10:36 |
bshum |
Might have found a quirk with the keep things at zero code |
| 10:37 |
Bmagic |
pinesol_green++ #Princess Bride |
| 10:37 |
pinesol_green |
Bmagic: You probably want hard-boiled eggs. |
| 10:37 |
bshum |
So on checking in a lost item |
| 10:37 |
bshum |
That was migrated with a status of lost |
| 10:37 |
bshum |
And not actually associated to any particular circulation or billing |
| 10:37 |
bshum |
We get a network failure |
| 10:37 |
bshum |
Can't call method \"id\" on an undefined value at /usr/local/share/perl/5.14.2/OpenILS/Application/Circ/Circulate.pm line 2536. |
| 10:38 |
bshum |
Looking at that line in Circulate.pm, I find that it's attempting something with the dont_change_lost_zero |
| 10:38 |
jeff |
can you reproduce on a test system and try with and without that setting enabled? |
| 10:39 |
Bmagic |
When we migrate lost items, we make the status "missing" |
| 10:39 |
bshum |
jeff: I'll see if I can find the same item in our test system. Not sure if it's synced enough |
| 10:40 |
Dyrcona |
bshum: I believe the key is in your 3rd line. |
| 10:40 |
Dyrcona |
I'd just change the copy status to missing and try checking it in again. |
| 10:41 |
Dyrcona |
Bmagic++ |
| 10:41 |
bshum |
Dyrcona: Sure, but it's not something that staff can do on their end of things. |
| 10:41 |
eeevil |
bshum: oh no? they should be able to use item status to set it to missing |
| 10:41 |
Dyrcona |
Right, but it's bad data nonetheless. |
| 10:41 |
bshum |
I wonder if there ought to be some additional code that only doesn't reopen bills that are already zero, but also skips over it, if there isn't a bill to be found. |
| 10:42 |
jeff |
it's difficult to be defensive AND not do unpredictable things given unpredictable data. |
| 10:42 |
Dyrcona |
Well, for LOST, there should be a circulation with a bill tied to it. |
| 10:42 |
bshum |
eeevil: It doesn't seem to be an option when I tried it anyways. I thought "Lost" was one of those statuses that people couldn't edit directly via the client. |
| 10:43 |
eeevil |
ah, that may be true |
| 10:43 |
jeff |
it might be possible to fix this, but it might also be possible that the best fix (that doesn't add "work around bshum's migrated data" to the codebase is "bshum needs to batch update the migrated data that is breaking convention/assumption. |
| 10:43 |
bshum |
jeff: Sure. |
| 10:43 |
* bshum |
is happy to blame the people who migrated the data ;) |
| 10:43 |
Dyrcona |
It's blowing up on this "$self->circ->id" 'cause there's no circ for that copy. |
| 10:43 |
jeff |
not advocating either approach, just pointing out that sometimes we probably DO have to say "umm, something's Just Not Right here!" :-) |
| 10:44 |
bshum |
but I wonder how often people might migrate lost items this method |
| 10:44 |
bshum |
Personally I don't feel there's a problem with marking an item lost |
| 10:44 |
* bshum |
wonders what that'll do for items that are marked lost but not checked out. |
| 10:44 |
Dyrcona |
Trouble is "lost" doesn't always have the same semantics from system to system. |
| 10:44 |
eeevil |
bshum: hopefully not too often, because lost has a special meaning that assumes a circ (in several areas) |
| 10:44 |
Dyrcona |
Or in English for that matter. |
| 10:45 |
eeevil |
"lost" means "a patron lost it", and the circ is how we "blame" the losing patron |
| 10:45 |
Dyrcona |
bshum: To be safe, you should probably find all lost copies that do not have a circ and change the status to missing. |
| 10:45 |
jeff |
we try to reserve Lost for "lost by patron (and/or longoverdue, since we don't use longoverdue yet)" and missing for "this was not found" and we have "Gone" for "we gave up on ever getting this back long ago, and we have purged the circ / never migrated the circ, etc. |
| 10:46 |
Dyrcona |
eeevil: Yeah, but in general lost, just means missing, and people can get easily confused thinking the ILS (any ILS) understands English. :) |
| 10:46 |
eeevil |
Dyrcona: indeed. as you say... |
| 10:46 |
eeevil |
software-- |
| 10:46 |
eeevil |
;) |
| 10:46 |
Dyrcona |
people-- ;) |
| 10:47 |
Dyrcona |
heh |
| 10:47 |
bshum |
Dyrcona: Yeah, that's logical, but I'm afraid I'll have to run that by all the powers that be before I do it. |
| 10:47 |
bshum |
I get the sense that people might not like that idea initially. |
| 10:47 |
Dyrcona |
Well, it's technically a flaw in your data migration, so you're just fixing it. |
| 10:48 |
|
mmorgan joined #evergreen |
| 10:50 |
dbwells |
bshum: When we migrated, we set all of our old system lost items to a custom "Lost (legacy)" status. I don't know if any of those ever came back, or what happened if they did, but at least they are cordoned off into their own problem area. |
| 10:50 |
jeff |
bshum: other options include a new copy status for Lost before Migration, etc. |
| 10:50 |
jeff |
or Gone, etc. :-) |
| 10:50 |
jeff |
but yeah, communication before batch changes often helps. |
| 10:51 |
bshum |
Makes sense. I guess I'll have a chat with the powers that be. |
| 10:51 |
* bshum |
starts constructing a query to find all these nonsense copies |
| 10:51 |
|
Shae joined #evergreen |
| 10:53 |
bshum |
And yes, changing the item's status to "missing" (via the DB) allows us to check it in properly. |
| 10:56 |
* bshum |
notes for the record that one cannot mark an item lost via Item Status, only missing or damaged. |
| 10:56 |
bshum |
So that's a relief. |
| 10:59 |
Bmagic |
Where is the table/column in the DB that is best suited for searching for ISBN from the console? |
| 10:59 |
Bmagic |
direct db query I mean |
| 11:00 |
* bshum |
only has to move like 36k "lost" items to a new fake status. No problemo... |
| 11:01 |
jeff |
bshum: pretty sure you can mark an item Lost via item status, you just have to be creative. :-) |
| 11:01 |
bshum |
jeff: You're probably right. |
| 11:02 |
jeff |
copy templates used to be enough, but now you might need to export + modify + import a copy template to get the item attribute editor to do your dirty work. |
| 11:02 |
bshum |
jeff: Right, cause by default it'd be excluded as a selectable choice. |
| 11:02 |
bshum |
But that sounds dastardly evil :) |
| 11:03 |
|
krvmga joined #evergreen |
| 11:04 |
berick |
bshum: he may not be the jeff we want, but he's the jeff we need. |
| 11:05 |
Bmagic |
select * from metabib.identifier_field_entry where field in(18,29) and value ~'9780763628345' takes 10 seconds. Can I beat that somehow? |
| 11:05 |
|
ohiojoe joined #evergreen |
| 11:05 |
bshum |
Bmagic: What about reporter.materialized_simple_record? |
| 11:06 |
Bmagic |
hmmmm, let me check that out |
| 11:06 |
bshum |
Isn't ISBN in there as an array |
| 11:06 |
* bshum |
tries to shape a better query cause apparently SELECT target_copy FROM action.circulation; is too darn slow :) |
| 11:07 |
* bshum |
supposes WHERE stop_fines = 'LOST' might be reasonably sufficient |
| 11:11 |
* kmlussier |
wonders if any of her sites migrated lost items to a lost status. :/ |
| 11:11 |
Bmagic |
select * from reporter.materialized_simple_record where '9780763628345' = any(isbn) 775 miliseconds! there we go |
| 11:12 |
Bmagic |
bshum++ |
| 11:13 |
bshum |
kmlussier: Yeah, I'd be curious to see who else might potentially run afoul of this issue. |
| 11:14 |
bshum |
I'm still trying to come up with a better (read: faster) way of figuring out which copies are lost and not connected to circs of any kind. |
| 11:14 |
mmorgan |
bshum: kmlussier: We migrated "billed" items to a Lost status, but I think we migrated associated transactions for those. |
| 11:15 |
mmorgan |
We haven't run into bshum's issue that I'm aware of. |
| 11:15 |
kmlussier |
Even if it is a flaw in the data migration, I'm worried that there may be several sites that have that flaw. How hard would it be to do a fix so that those flawed migrated items are handled better? |
| 11:16 |
* bshum |
lets his test database churn on a query while he drives over to the office for the next round of meetings... |
| 11:19 |
Bmagic |
bshum: does this help identify the situation you are in? select * from asset.copy where status=3 and id not in(select target_copy from action.circulation) |
| 11:20 |
Dyrcona |
Bmagic: He's doing that one already. Thinks he's missing an index, 'cause it's taking forever. |
| 11:20 |
Bmagic |
I see |
| 11:20 |
* mmorgan |
was thinking of a similar query, but added "and deleted is false" |
| 11:21 |
mmorgan |
... and found 131 items :-( |
| 11:21 |
* kmlussier |
personally thinks a bug should be filed. |
| 11:21 |
Dyrcona |
I ran this: select acp.id from asset.copy acp where acp.status = 3 and not acp.deleted and acp.id not in (select target_copy from action.circulation) |
| 11:21 |
Dyrcona |
Took 9 seconds on my test database the first time. |
| 11:21 |
* mmorgan |
agrees with kmlussier |
| 11:22 |
jeff |
kmlussier: to answer your question, i don't know -- haven't looked. no objection to a bug being filed as a next step to getting an eye on it. |
| 11:22 |
Bmagic |
yeah, my test db returned 2100 rows in 10 seconds |
| 11:25 |
Dyrcona |
I get 807, and after pulling out dates and doing some sorting, looks like all but 6 come from migration. |
| 11:26 |
Dyrcona |
Most recent one is from July of 2013. |
| 11:27 |
|
bmills joined #evergreen |
| 11:28 |
Dyrcona |
Fixing bshum's specific message would be as simple as adding "&& $self->circ" in the if statement on line 2,535 of Circulate.pm. |
| 11:28 |
Dyrcona |
Dunno if that would then expose other places where a circ is assumed to exist. |
| 11:30 |
mmorgan |
To expand on kmlussier's question: In general, when one of those network errors pops up in the client, how hard is it to make that message friendlier? Or does it depend on each circumstance? |
| 11:31 |
Dyrcona |
mmorgan: Very often when that message pops up, the client doesn't actually know what happened. It just knows something failed. |
| 11:39 |
mmorgan |
Dyrcona: ok, but there are those "Unhandled Error"s where you can see the problem if you look hard past the skull and crossbones. The ones that say FIXME: How hard are those to fix? |
| 11:41 |
Dyrcona |
mmorgan: Dunno, really. However, I'd say "won't fix" because XUL client. That effort would be better spent on the web staff client. |
| 11:42 |
mmorgan |
Yes, very true. |
| 11:46 |
jeff |
" |
| 11:46 |
jeff |
(missed a closing quote about seven messages back) |
| 11:47 |
eeevil |
jeff: thanks, my parser was getting angry |
| 11:47 |
mmorgan |
Heh. Maybe that's what caused bshum's errors :) |
| 11:49 |
jeff |
eeevil: it was really messing with my syntax hilighting, y'know? |
| 11:50 |
eeevil |
jeff: I don know. related: $$-quoting is great, but vim needs a new PG rule |
| 11:51 |
eeevil |
do know, I don't don |
| 11:51 |
jeff |
$$ quoting IS great. |
| 11:52 |
jeff |
at some point, if your editor isn't embedding libpq or portions thereof, your syntax highlighting is going to have... gaps. |
| 11:53 |
jeff |
(i don't actually think that -- i'm pretty sure with a little work the vim syntax rules could be updated -- but the idea of your editor including libpq amused me) |
| 11:54 |
eeevil |
jeff: I'll leave that to the emacs users to work on |
| 11:54 |
* eeevil |
ducks |
| 12:37 |
jeff |
i knew that would lead to an emacs reference sooner or later. |
| 12:38 |
mnsri |
jboyer-isl++ on the ansible presentation. |
| 12:50 |
|
buzzy joined #evergreen |
| 13:02 |
|
jihpringle joined #evergreen |
| 13:11 |
|
pgardella joined #evergreen |
| 13:30 |
Bmagic |
If anyone needs to migrate a library that only has ISBN's and some rough data that represent their titles, let me know! This code attempts to collect the MARC from EG,z39.50,chopac,original in that order |
| 13:34 |
jeff |
why am i sitting at my desk with my laptop closed, resting on my shoulder next to my ear? |
| 13:34 |
jeff |
no reason. :-P |
| 13:34 |
Bmagic |
feff: awww, so cute |
| 13:34 |
Bmagic |
jeff: awww, so cute |
| 13:34 |
Bmagic |
lol |
| 13:35 |
* jeff |
holds down power button |
| 13:35 |
jeff |
"ssh... it'll all be over soon..." |
| 13:38 |
jeff |
@blame Eclipse |
| 13:38 |
pinesol_green |
jeff: Eclipse stole bshum's tux doll! |
| 13:40 |
|
graced joined #evergreen |
| 13:55 |
|
bmills joined #evergreen |
| 14:07 |
kmlussier |
@coffee |
| 14:07 |
* pinesol_green |
brews and pours a cup of Kenya Peaberry Kirinyaga Kii, and sends it sliding down the bar to kmlussier |
| 14:10 |
kmlussier |
pinesol_green: No, that's not good enough. I think I need the real thing. |
| 14:10 |
pinesol_green |
kmlussier: If all else fails, try this: http://en.wikipedia.org/wiki/Rubber_duck_debugging |
| 14:10 |
pinesol_green |
kmlussier: I am only a bot, please don't think I'm intelligent :) |
| 14:23 |
jeff |
@coffee kmlussier |
| 14:23 |
* pinesol_green |
brews and pours a cup of Guatemala Xeucalvitz, and sends it sliding down the bar to kmlussier |
| 14:31 |
|
dMiller_ joined #evergreen |
| 14:49 |
jboyer-isl |
mnsri: Glad it was informative. I'm hoping something to have something share-worthy next week. |
| 14:50 |
mnsri |
jboyer-isl: I saw this live when i was at conference, but was looking for slides . Thank you for sending that |
| 15:14 |
kmlussier |
Since we tend to see a lot of new faces in the #evergreen channel after the conference, I think now is a good time to remind everyone to add themselves to the wiki page listing who's who in IRC. http://evergreen-ils.org/dokuwiki/doku.php?id=community:irc_channel |
| 15:14 |
kmlussier |
I'm sure yboston will be sending this reminder during the IRC practice session too. :) |
| 15:16 |
* kmlussier |
sees a lot of names that don't come around here much anymore. :( |
| 15:17 |
bshum |
So today was a day for maintenance releases. |
| 15:17 |
bshum |
According to the calendar. |
| 15:18 |
|
pgardella joined #evergreen |
| 15:50 |
dbs |
Fascinating, reporter.materialized_simple_record is aggregating OCLC work entity URIs into the isbn[] column |
| 15:51 |
dbs |
e.g. https://laurentian.concat.ca/eg/opac/record/2090263?expand=marchtml#marchtml (pulls from the 024 apparently) |
| 15:51 |
bshum |
Interesting... |
| 15:52 |
bshum |
@marc 024 |
| 15:53 |
pinesol_green |
bshum: A standard number or code published on an item which cannot be accommodated in another field (e.g., field 020 (International Standard Book Number), 022 (International Standard Serial Number) , and 027 (Standard Technical Report Number)). The type of standard number or code is identified in the first indicator position or in subfield $2 (Source of number or code). (Repeatable) [a,c,d,z,2,6,8] |
| 15:55 |
dbs |
LEFT JOIN metabib.full_rec isbn ON r.id = isbn.record AND (isbn.tag = ANY (ARRAY['024'::bpchar, '020'::bpchar])) AND (isbn.subfield = ANY (ARRAY['a'::text, 'z'::text])) |
| 15:55 |
bshum |
dbs: So I can see 024 is part of the definition for ISBN |
| 15:55 |
bshum |
Yeah |
| 15:55 |
dbs |
yeah |
| 15:56 |
dbs |
That seems... aggressive |
| 15:56 |
* bshum |
doesn't have a strong opinion on it. |
| 15:58 |
bshum |
Hmm |
| 15:59 |
bshum |
Looks like it's always looked for 024 and 020? |
| 15:59 |
* bshum |
wonders if it's a PINES-thing |
| 16:01 |
|
montgoc1 joined #evergreen |
| 16:15 |
bshum |
So yeah |
| 16:15 |
bshum |
A sequential scan on 27 million rows of action.circulation apparently takes awhile to work |
| 16:17 |
dbs |
hah |
| 16:18 |
bshum |
I left our test DB running with the query to try finding all the bad "lost" items and it was still running this afternoon when I went to check on it. Around 4+ hours later. |
| 16:18 |
bshum |
So.... I'll think about better ways of finding that faster. |
| 16:18 |
jeff |
what was your query, again? |
| 16:19 |
bshum |
jeff: Mine was a very generic SELECT COUNT(*) FROM asset.copy WHERE status = 3 AND deleted = FALSE AND id NOT IN (SELECT target_copy FROM action.circulation); |
| 16:19 |
bshum |
The scan on getting target_copy from action.circulation is what's slowing me down |
| 16:19 |
bshum |
Just curious to find the number... not even working on fixing it yet. |
| 16:20 |
bshum |
When I ran it against just stuff with WHERE stop_fines = 'LOST' |
| 16:20 |
bshum |
I came up with about 36k items |
| 16:22 |
bshum |
Given that we've never encountered this problem before, I'm tempted to try Dyrcona's suggestion and add something to Circulate.pm to work around the weirdness. |
| 16:22 |
bshum |
But I'll figure out why my database is weird soon enough. |
| 16:23 |
bshum |
Or how to improve the process. |
| 16:27 |
bshum |
fwiw, there is an action_circulation_target_copy_idx index on action.circulation |
| 16:27 |
bshum |
But I haven't quite gotten it to do anything yet. |
| 16:29 |
jonadab |
bshum: Is it possible that it's doing the sub-SELECT for every row in asset.copy that matches the other criteria? |
| 16:30 |
bshum |
jonadab: Maybe, but just doing SELECT target_copy FROM action.circulation; alone takes... well, quite forever. |
| 16:30 |
jonadab |
Ah. |
| 16:30 |
bshum |
Basically I just have too many rows I guess. |
| 16:30 |
* bshum |
should start aging his circs |
| 16:30 |
|
wongon joined #evergreen |
| 16:30 |
bshum |
But then I'd have to run it against the combined circ view |
| 16:31 |
bshum |
And it'll probably still be slow. |
| 16:31 |
jeff |
bshum: try this instead: |
| 16:31 |
jeff |
SELECT COUNT(*) FROM asset.copy acp WHERE acp.status = 3 AND NOT acp.deleted AND EXISTS (SELECT 1 FROM action.circulation circ WHERE circ.id = acp.id); |
| 16:31 |
jeff |
sorry, not that. |
| 16:31 |
jonadab |
Yeah, I was just going to say WHERE (SELECT COUNT(*) FROM action.circulation WHERE target_copy = id); |
| 16:31 |
bshum |
Yeah I was going to say |
| 16:31 |
jeff |
flip to NOT EXISTS: |
| 16:31 |
jeff |
SELECT COUNT(*) FROM asset.copy acp WHERE acp.status = 3 AND NOT acp.deleted AND NOT EXISTS (SELECT 1 FROM action.circulation circ WHERE circ.id = acp.id); |
| 16:32 |
jonadab |
Or, yes, = 0 |
| 16:32 |
jonadab |
So yeah. |
| 16:32 |
jeff |
NOT IN ([millions of values]) is very expensive. |
| 16:32 |
bshum |
but circ.id != acp.id |
| 16:32 |
jeff |
and you aren't using the value of action.circulation.target_copy other than to tie things together, so there's no point in keeping it. |
| 16:32 |
jeff |
er. |
| 16:32 |
jeff |
oh -- HAH |
| 16:32 |
Dyrcona |
7.2 million is not so bad, but 21 million is more than 3x worse in terms of performance. ;) |
| 16:32 |
jeff |
yeah, sorry. |
| 16:33 |
bshum |
But I get where you're going |
| 16:33 |
jeff |
SELECT COUNT(*) FROM asset.copy acp WHERE acp.status = 3 AND NOT acp.deleted AND NOT EXISTS (SELECT 1 FROM action.circulation circ WHERE circ.target_copy = acp.id); |
| 16:33 |
jeff |
that should be better. |
| 16:33 |
jeff |
:-) |
| 16:33 |
jonadab |
Yeah, that looks good. |
| 16:33 |
bshum |
jeff: Yes, that works, and invokes the index |
| 16:33 |
bshum |
And voila, magic fast |
| 16:34 |
bshum |
Just 35682 copies to deal with... huzzah |
| 16:34 |
collum |
yep. Just ran the same query on my test machine. It runs exponentially faster. |
| 16:34 |
Dyrcona |
Takes only about 1 second less on my data, but that's still an improvement. :) |
| 16:34 |
|
buzzy joined #evergreen |
| 16:34 |
jeff |
yeah. completes in 623ms for me on a very very underpowered test instance. |
| 16:34 |
bshum |
2244 ms. Vs. how 4+ hours and incomplete? Yeah seems like a win. |
| 16:35 |
jeff |
http://i.imgur.com/IW8simF.gif |
| 16:35 |
bshum |
jeff++ |
| 16:36 |
bshum |
Course now I have to finish convincing everyone to feel okay about adding a new copy_status |
| 16:36 |
* bshum |
goes back to writing the long email |
| 16:36 |
jeff |
that and getting away from WHERE timestamp::DATE BETWEEN are great performance tricks. |
| 16:37 |
jeff |
well, they're handy and i find myself using them often. |
| 16:38 |
Dyrcona |
pssht. I'd just set them to missing and call it a day. |
| 16:39 |
bshum |
I used to do stuff like that. |
| 16:39 |
* bshum |
wonders when he got all cautious and stuff |
| 16:40 |
jeff |
for anyone following along at home, WHERE timestamp::DATE BETWEEN date1 date2 can be slow because it will cast every timestamp to DATE in order to do the comparison. |
| 16:42 |
jeff |
better to do something like (the more verbose, but speed-bringing) WHERE timestamp BETWEEN date1::DATE and (date2::DATE + '1 day'::INTERVAL)::DATE |
| 16:43 |
* jeff |
ponders subtracting a second |
| 16:46 |
jeff |
...timezones... |
| 16:47 |
* jeff |
stands by his original statement that "moving away from" X is better, without trying to fully enumerate Y Right Now |
| 16:49 |
tsbere |
jeff: I usually use date_trunc to a day. |
| 16:49 |
tsbere |
date_trunc(blah) BETWEEN... |
| 16:50 |
tsbere |
not 100% sure on the speed side of things, though |
| 16:55 |
jeff |
yeah, i suspect that casting blah and passing blah through a date function are both worse than just using a comparison operator on blah. |
| 16:55 |
bshum |
jboyer-isl: Bmagic: Sigh, so CollectionHQ question, do you guys run that extract for any whole systems of branches? Like say, SYS level not, BR level |
| 16:55 |
jeff |
bshum: we do |
| 16:56 |
bshum |
jeff: Is it as simple as putting the SHORTNAME for the system in place where the LIBRARYCODE goes? |
| 16:56 |
bshum |
Or am I way overthinking |
| 16:56 |
bshum |
*underthinking |
| 16:56 |
jeff |
bshum: see https://github.com/tadl/evergreen-contrib-equinox/commit/231f0a96ba01f54e1025659f5223bc5868ff6b6e |
| 16:57 |
bshum |
Oh |
| 16:57 |
bshum |
See, now I thought 1 was like, do it |
| 16:57 |
jeff |
bshum: you pass an org unit id in the get_bibs.sql and get_items.sql |
| 16:57 |
bshum |
Not 1 CONS |
| 16:57 |
bshum |
Gotcha. |
| 16:57 |
|
bmills joined #evergreen |
| 16:57 |
jeff |
yeah, i could have perhaps been more clear. |
| 16:57 |
bshum |
It's all good. |
| 16:57 |
bshum |
I should read instructions better ;) |
| 16:58 |
bshum |
But it's not super specific. |
| 16:58 |
jeff |
you'll note that i called it a "work-in-progress", even though we're just using it as-is here and never found need to go back and work further on it :-) |
| 16:58 |
bshum |
jeff: Yeah I'm trying it with jboyer-isl's additional patches |
| 16:58 |
bshum |
I'm thinking if I have to run this for two libraries |
| 16:58 |
bshum |
I should copy the collectionHQ stuff to two directories or something |
| 16:58 |
bshum |
And run them whatever |
| 16:58 |
bshum |
Well, edit and run them |
| 16:59 |
jeff |
i'd go with that, yes. |
| 17:03 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:07 |
bshum |
I should add to the README |
| 17:07 |
bshum |
Little things |
| 17:08 |
bshum |
Like install libemail-sender-perl |
| 17:08 |
bshum |
And edit sender-email.pl to point at localhost or whatnot rather than ESI's smtp :) |
| 17:08 |
bshum |
But it's alive! |
| 17:10 |
jeff |
install ftp, configure .netrc or similar, etc, etc. |
| 17:11 |
bshum |
Right |
| 17:13 |
jeff |
https://gist.github.com/jeff/c9f529f227590640fd49 is one example of doing a weekly extract and a routine monthly extract on a specific date (and not doing TWO when they align) |
| 17:14 |
jeff |
the extracts are identical, but "weekly" vs "monthly" is treated differently on their end. |
| 17:14 |
bshum |
Gotcha. |
| 17:19 |
|
mmorgan left #evergreen |
| 17:21 |
Bmagic |
bshum: late to the party, yes, system level |
| 17:21 |
bshum |
Bmagic: All good, I'm going to toy with it more tomorrow after I get a response back from them. |
| 17:22 |
jeff |
that's optimistic! |
| 17:22 |
* jeff |
ducks |
| 17:23 |
Bmagic |
bshum: LIBRARYNAME= value is what you are referring? |
| 17:23 |
bshum |
Bmagic: Yeah originally I thought that was meant to be the system name or something. |
| 17:23 |
bshum |
But it's not what drives it. |
| 17:25 |
Bmagic |
bshum: right, as far as I can tell, that value is dropped in the file header |
| 17:28 |
jeff |
it is used by chq |
| 17:37 |
jeff |
a customer code, essentially |
| 17:54 |
|
Dyrcona joined #evergreen |
| 17:58 |
mrpeters |
anyone with control of the dokuwiki able to change my email address (i can't reset my password because its my old ISL account)? |
| 17:59 |
mrpeters |
I would make a new account, but would like to retain my username/history |
| 18:22 |
|
wlayton joined #evergreen |
| 18:53 |
|
wlayton joined #evergreen |
| 19:14 |
|
wongon_ joined #evergreen |
| 19:20 |
|
dcook joined #evergreen |
| 20:14 |
|
buzzy joined #evergreen |
| 20:50 |
|
bmills joined #evergreen |
| 21:31 |
|
wongon joined #evergreen |
| 22:47 |
|
montgoc1 joined #evergreen |
| 22:54 |
kmlussier |
@later tell mrpeters Send me your email address in a pm, and I'll update your wiki account. |
| 22:54 |
pinesol_green |
kmlussier: The operation succeeded. |
| 23:03 |
bshum |
@later tell mrpeters I fixed it for you. |
| 23:03 |
pinesol_green |
bshum: The operation succeeded. |
| 23:05 |
|
pgardella joined #evergreen |
| 23:06 |
|
Newziky1 joined #evergreen |
| 23:13 |
kmlussier |
@karma |
| 23:13 |
pinesol_green |
kmlussier: Highest karma: "dbs" (994), "bshum" (974), and "tsbere" (668). Lowest karma: "ie" (-62), "^" (-30), and "marc" (-28). You (kmlussier) are ranked 5 out of 2482. |
| 23:13 |
bshum |
@unload Karma |
| 23:13 |
pinesol_green |
bshum: The operation succeeded. |
| 23:13 |
kmlussier |
@karma |
| 23:13 |
pinesol_green |
kmlussier: Sorry, that command is only available to Evergreen Premium™ Subscribers. Please upgrade your subscription ASAP! |
| 23:14 |
kmlussier |
Hee hee |
| 23:14 |
bshum |
@load Karma |
| 23:14 |
pinesol_green |
bshum: The operation succeeded. |
| 23:14 |
kmlussier |
@karma |
| 23:14 |
pinesol_green |
kmlussier: Error: I have no karma for this channel. |
| 23:14 |
kmlussier |
Weird! |
| 23:14 |
* jeff |
yawns |
| 23:14 |
jeff |
@coffee |
| 23:14 |
* pinesol_green |
brews and pours a cup of Ethiopia Washed Yirgacheffe, Koke Grade 1, and sends it sliding down the bar to jeff |
| 23:14 |
bshum |
parts-- |
| 23:14 |
bshum |
Hmm |
| 23:14 |
kmlussier |
bshum++ #Resetting karma |
| 23:14 |
kmlussier |
@karma |
| 23:14 |
pinesol_green |
kmlussier: Highest karma: "bshum" (1) and "parts" (-1). Lowest karma: "parts" (-1) and "bshum" (1). |
| 23:14 |
kmlussier |
bshum: You're number 1 |
| 23:14 |
bshum |
kmlussier: Won't last long |
| 23:15 |
kmlussier |
Though I now regret giving you karma since you already slapped parts down. |
| 23:15 |
kmlussier |
parts++ |
| 23:16 |
kmlussier |
bshum: Couldn't we have a karma war over something else this year? |
| 23:16 |
bshum |
cookies++ |
| 23:17 |
bshum |
kmlussier: I'm sure we'll think of something. |
| 23:17 |
bshum |
kmlussier++ |
| 23:18 |
* bshum |
hates parts less and less over time. |
| 23:22 |
jeff |
that's probably good. |
| 23:23 |
jeff |
tonight i hate SSL client libraries |
| 23:23 |
kmlussier |
@hates bshum |
| 23:24 |
pinesol_green |
bshum hates metarecord holds; acquisitions; questions about acquisitions; z39.50; acq; notices; action triggers; marc_export; hold pull lists; drupal; holds; RDA; edi; parts holds; kpac; SIP; parts; marc; RAID; Launchpad; edi troubleshooting; reports; serials; apostrophes in search; zimbra; office printer; weird barcodes; PO JEDI; B&T; using the phone; horizontal summary display; vertical (1 more message) |
| 23:24 |
bshum |
Aww... |
| 23:24 |
bshum |
Oh good. |
| 23:24 |
bshum |
I was thinking @hate not @hates :) |
| 23:24 |
kmlussier |
I would never hate on you bshum! |
| 23:24 |
jeff |
@more kmlussier |
| 23:24 |
pinesol_green |
jeff: summary display; backporting; A/T; custom reporter stuff; dojo; and snow |
| 23:24 |
jeff |
"and snow" |
| 23:25 |
kmlussier |
@hates |
| 23:25 |
pinesol_green |
kmlussier hates git; Launchpad search; Internet Explorer; snow; scheduling meetings; Starbucks; negative balances; undrinkable coffee; winter; blizzards; and spam |
| 23:25 |
kmlussier |
I probably don't hate git anymore, but am not quite ready to move it into the love column. |
| 23:26 |
kmlussier |
@loves |
| 23:26 |
pinesol_green |
kmlussier loves parts; YAOUS; Fridays; clam chowder; coffee; new fanged email thing; quassel; magic eightball; trivia; Evergreeners; BBQ; spell check; mobile catalog; new edit links in the catalog; vim; pizza; grep; spring; summer; fall; and clam chowdah |
| 23:26 |
jeff |
i know why i'm up -- why are you two still up? |
| 23:26 |
* kmlussier |
is wasting time playing games. |
| 23:28 |
bshum |
For logs, I can this output for karma DB: http://evergreen-ils.org/~bshum/karma.final.txt |
| 23:28 |
bshum |
*ran/can |
| 23:29 |
bshum |
jeff: I took a nap earlier, so I'm awake. Sorta. |
| 23:30 |
bshum |
Actually no, I was thinking to sleep again. |
| 23:33 |
* jeff |
installs a vm to install a proxy to stick between two apps that are no longer on speaking terms |
| 23:44 |
* kmlussier |
shifts her attention to Letterman |
| 23:48 |
|
bmills joined #evergreen |
| 23:50 |
kmlussier |
Heh, I just noticed that c had 19 karma points |
| 23:52 |
kmlussier |
Ha ha. It looks like bhsum stole five of your karma points bshum. :) |
