| Time |
Nick |
Message |
| 06:40 |
|
rlefaive joined #evergreen |
| 06:57 |
|
rlefaive joined #evergreen |
| 06:58 |
|
tsbere_ joined #evergreen |
| 07:01 |
|
rlefaive joined #evergreen |
| 07:40 |
|
ericar joined #evergreen |
| 07:52 |
|
JBoyer joined #evergreen |
| 08:00 |
|
rlefaive joined #evergreen |
| 08:18 |
|
collum joined #evergreen |
| 08:38 |
|
mrpeters joined #evergreen |
| 09:00 |
|
jwoodard joined #evergreen |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:04 |
|
wlayton joined #evergreen |
| 09:13 |
|
rjackson_isl joined #evergreen |
| 09:30 |
|
yboston joined #evergreen |
| 09:37 |
|
maryj joined #evergreen |
| 09:58 |
|
mmorgan joined #evergreen |
| 10:20 |
|
tspindler joined #evergreen |
| 10:21 |
|
tspindler left #evergreen |
| 10:34 |
|
Christineb joined #evergreen |
| 10:37 |
|
mmorgan1 joined #evergreen |
| 11:00 |
mmorgan1 |
For those of you using PayPal to accept online credit card payments, what kind of PayPal account do you have? Are you paying $30 per month for a pro account? |
| 11:14 |
|
lualaba joined #evergreen |
| 11:14 |
lualaba |
Hello. i try to import gutenberg project marc records. when i try to make bre file got error: Use of uninitialized value $tag in hash element at /usr/share/perl5/MARC/Record.pm line 202. |
| 11:17 |
Dyrcona |
lualaba: That sounds like a bad record on the input. |
| 11:19 |
lualaba |
but i download from http://www.gutenberg.org/cache/epub/feeds/catalog.marc.bz2 |
| 11:19 |
lualaba |
how can be there bad records? also i try to download here http://wiki.evergreen-ils.org/doku.php?id=evergreen-admin:importing:bibrecords |
| 11:20 |
Dyrcona |
lualaba: You did follow the suggests of the bold text in read at the top of the second URL, right? |
| 11:20 |
* Dyrcona |
cannot type today. |
| 11:21 |
Dyrcona |
lualaba: Also, the Gutenberg records are already binary MARC, you don't have to do anything to convert them, except bunzip them. |
| 11:21 |
lualaba |
note that is older instruction? |
| 11:22 |
lualaba |
and how to import in db binary MArc records? |
| 11:23 |
Dyrcona |
lualaba: Try Vandelay. I was able to import the Gutenberg records through Vandelay last time I tried in 2012. |
| 11:24 |
Dyrcona |
The client timed out, but the import eventually finished. |
| 11:24 |
lualaba |
i use version 2.8.1 |
| 11:25 |
Dyrcona |
Vandelay is the "MARC Batch Import/Export" option on the cataloging menu. |
| 11:25 |
Dyrcona |
The documentation should tell you all you need to know. |
| 11:25 |
lualaba |
i know but there is any limit or need time? |
| 11:26 |
lualaba |
after 1000 records i don't see any progress |
| 11:26 |
Dyrcona |
lualaba: In my experience, the client times out, but the import continues just the same. |
| 11:26 |
Dyrcona |
I usually write my own scripts to import records. |
| 11:26 |
lualaba |
i also write my own scripts for usual marc xml file |
| 11:27 |
lualaba |
and insert it directly in DB |
| 11:27 |
|
jvwoolf1 joined #evergreen |
| 11:27 |
berick |
indeed, there is a bug where status updates stop arriving on the client side even though the server continues to process. |
| 11:27 |
lualaba |
ok i will try with marc batch import |
| 11:28 |
lualaba |
thank you |
| 11:28 |
lualaba |
if there is not any other methods |
| 11:29 |
Dyrcona |
lualaba: Well, you could always write a script to load the records. |
| 11:29 |
lualaba |
sure |
| 11:29 |
lualaba |
but why evergreen conait a lot unused scripts? |
| 11:30 |
lualaba |
i wrote script in perl and directly inserting in DB but may i missed some tables |
| 11:30 |
lualaba |
i have 25 K records know everything is working fine |
| 11:33 |
|
lualaba_ joined #evergreen |
| 11:34 |
Dyrcona |
I'm not sure I follow your question about unused scripts. |
| 11:34 |
Dyrcona |
A lot of the examples on the wiki are old, and the one you pointed to says as much and recommends you look at the documentation for your version of Evergreen. |
| 11:35 |
lualaba_ |
documentation is oriented for catalogers, not for admins |
| 11:36 |
Dyrcona |
Catalogers are expected to be the ones doing the imports. |
| 11:36 |
Dyrcona |
When we have something that needs regular updates, I write a script to download the updates and manage it all. |
| 11:36 |
lualaba_ |
but if you have file with 40 K records with staff client it is impossible |
| 11:37 |
Dyrcona |
The staff client times out, yes, but the load continues. |
| 11:37 |
Dyrcona |
Typically, you'd break the file up into smaller chunks before hand. |
| 11:38 |
Dyrcona |
I'll be the first to complain that the staff client is not useful for batch operations. |
| 11:38 |
yboston |
Dyrcona++ |
| 11:38 |
lualaba_ |
yes this is rigth |
| 11:39 |
lualaba_ |
one question: when i make insert directly in DB inserting in (biblio.record_entry, asset.copy, asset.call_number) need anything else? |
| 11:40 |
Dyrcona |
lualaba_: Generally, no. Database triggers take care of the rest. |
| 11:40 |
Dyrcona |
With electronic records, like Gutenberg, I'll just insert them. |
| 11:40 |
lualaba_ |
but what about preffix and suffix? which is not inserting automaticaly |
| 11:41 |
Dyrcona |
lualaba_: You need to determine the prefix and suffix yourself when making the call number. |
| 11:42 |
Dyrcona |
One reason to use scripts with electronic records is to modify the 856 tags on the way in. |
| 11:42 |
lualaba_ |
you have any good documentation for DB? |
| 11:42 |
Dyrcona |
You can do that in code and save the catalogers the time of doing it in MARCEdit or whatever. |
| 11:42 |
lualaba_ |
i just upfate source with 3 in this case |
| 11:43 |
Dyrcona |
You can set the source on the way in or after the fact, yeah. |
| 11:43 |
Dyrcona |
As for DB documentation, I don't personally have any. |
| 11:43 |
Dyrcona |
I mostly poke around with PgAdmin to see what's what. |
| 11:43 |
lualaba_ |
same here :) |
| 11:43 |
lualaba_ |
but i spent a lot of time |
| 11:44 |
Dyrcona |
Also, I highly recommend having a test/development database set up so you don't break production. |
| 11:44 |
Dyrcona |
Yes, it is time consuming. |
| 11:44 |
lualaba_ |
what i need now is to know relations between tables |
| 11:45 |
Dyrcona |
I think someone made a relational chart of the database once, but I could have hallucinated that. |
| 11:45 |
lualaba_ |
oh, this will be a helpful for me |
| 11:47 |
lualaba_ |
ok thank you i will join later |
| 11:50 |
Dyrcona |
lualaba_: There is this http://docs.evergreen-ils.org/dev/schema/ |
| 11:50 |
Dyrcona |
It's not what I was thinking of, but if you click on a table it does tell you what tables/fields have relations to others. |
| 11:51 |
|
lualab joined #evergreen |
| 11:53 |
Dyrcona |
lualab: Check this: http://irc.evergreen-ils.org/evergreen/2016-02-09#i_227599 |
| 12:08 |
|
berick joined #evergreen |
| 12:14 |
|
mmorgan joined #evergreen |
| 12:16 |
|
bmills joined #evergreen |
| 12:24 |
|
rlefaive joined #evergreen |
| 12:25 |
|
jihpringle joined #evergreen |
| 12:35 |
Dyrcona |
Does changing the "When enabled, Located URIs will provide visibility behavior identical to copies" flag require anything beyond just changing the flag? |
| 12:36 |
Dyrcona |
I'm just asking before I try it, so no implied failure of it to do what was expected in that question. |
| 12:36 |
jeff |
iirc, the only thing you'd need to worry about is cached searches. |
| 12:39 |
Dyrcona |
jeff: Thanks. I'll find a couple of records and give it a whirl. |
| 12:40 |
jeff |
yeah, looks like the flag is consulted by evergreen.located_uris and search.query_parser_fts only (barring any clever / generated references) |
| 12:41 |
Dyrcona |
Cool. |
| 12:43 |
Dyrcona |
Hmm. We have a couple of these that have a 856 that only has a $9.... |
| 12:43 |
Dyrcona |
But, those records have other 856s with everything in it, with a different value for $9. |
| 12:43 |
Dyrcona |
The ones with the $9 by itself the value of $9 is the consortium shortname. |
| 12:44 |
Dyrcona |
Some how, I don't think that is enough to make it show up, but I'll do a search before changing the flag. |
| 12:45 |
Dyrcona |
And, I'm naturally logged in at the wrong library. :) |
| 12:45 |
Dyrcona |
But, it's a good test anyway. :) |
| 12:46 |
Dyrcona |
So, yep, the $9 MVC by itself doesn't do anything. The $u has to be there. |
| 12:50 |
jeff |
were you hoping to use/abuse the feature to have some records that didn't have URIs show up somewhere? |
| 12:50 |
jeff |
or just testing an edge case? |
| 12:53 |
Dyrcona |
jeff: Just testing what it does in general. |
| 12:53 |
* jeff |
nods |
| 12:53 |
Dyrcona |
We have a couple buckets of electronic records that catalogers/reference staff want things done to, so I'm testing some of those things. |
| 12:54 |
Dyrcona |
I'm not sure where the $9 MVC by itself comes, probably cataloging staff. |
| 12:54 |
Dyrcona |
I've not mangled the records for real, yet. :) |
| 12:54 |
Dyrcona |
Someone else was probably trying to get them to show up. |
| 12:54 |
Dyrcona |
jeff++ |
| 12:55 |
Dyrcona |
The flag does what I expected. Pretty much what the documentation says. |
| 12:56 |
jeff |
heh. what did i do? |
| 12:56 |
Dyrcona |
You answered my questions, when I was lazy. :) |
| 12:56 |
Dyrcona |
Anyway, others can decide if they want that flag enabled in production. |
| 12:57 |
* Dyrcona |
checks what's next on today's list. |
| 12:58 |
Dyrcona |
For the curious, in one bucket we're going to likely replace all of the 856 tags with one that is consortium-wide. |
| 12:58 |
Dyrcona |
In a second bucket, I'm likely going to do nothing if we activate that flag. |
| 12:59 |
Dyrcona |
Maybe move the records to a new source for grouping purposes, but not much else. |
| 13:00 |
Dyrcona |
git-integration-in-your-editor++ |
| 13:02 |
mmorgan |
Dyrcona: We have that flag enabled for some time. We have records with consortium-wide 856 fields and it works well for us. |
| 13:02 |
Dyrcona |
mmorgan: Yes, we've internally called the "NOBLE option" for short. :) |
| 13:03 |
Dyrcona |
Well, I have, anyway. |
| 13:03 |
mmorgan |
Heh. :) |
| 13:07 |
Bmagic |
just want to verify what I have found - clark kent is setup to -c 4 - and there is nothing happening. None of the 29 reports are running |
| 13:07 |
Dyrcona |
Bmagic: I'll take your word for it. :) |
| 13:07 |
Bmagic |
it looks like clark isn't doing anything because there are exactly 4 reports that have a complete_time null but start_time not null |
| 13:08 |
Dyrcona |
Bmagic: Does say he's reporting or waiting for trouble? |
| 13:08 |
|
kmlussier2 joined #evergreen |
| 13:08 |
Bmagic |
yes |
| 13:08 |
Bmagic |
waiting for trouble |
| 13:09 |
Dyrcona |
Sounds like something is wrong, then, but I'm not a reports expert. |
| 13:09 |
Dyrcona |
Have you tried restarting Clark? |
| 13:09 |
Bmagic |
yeah, I restarted clark |
| 13:10 |
Bmagic |
I think I just answered my own question - update reporter.schedule set start_time=null where id in(24722,24726) |
| 13:10 |
|
kitteh__ joined #evergreen |
| 13:10 |
Bmagic |
now, clark is doing something |
| 13:10 |
Dyrcona |
So, something in those two reports? Think they crashed? |
| 13:11 |
Dyrcona |
Actually, I think they crashed if start_time is not null and complete_time is null. |
| 13:11 |
kmlussier2 |
heh...the NOBLE option |
| 13:12 |
kmlussier2 |
NOBLE, the place where you can have unlimited coffee and Located URI's that appear in a consortium-wide search. :) |
| 13:12 |
jeff |
Bmagic: clark doesn't have any kind of stale report detection. |
| 13:13 |
Bmagic |
Dyrcona: jeff: yep - that is what is going on, 4 reports in reproter.schedule had a start_time but nothing in complete time. The dates were way back in 2012 |
| 13:13 |
Bmagic |
so, I just deleted the rows |
| 13:13 |
jeff |
Bmagic: if there are reports with a start_time and no complete_time, then they're "running" even if they aren't. |
| 13:13 |
Bmagic |
working now. Thanks - I was confused for a while. "Why isn't clark doing anything...." |
| 13:14 |
jeff |
if all four were from 2012, was this on a non-production system, or had you recently decreased clark's concurrency? |
| 13:14 |
mmorgan |
kmlussier: :-D |
| 13:14 |
jeff |
or has nobody run reports on that system since 2012? ;-) |
| 13:15 |
|
mmorgan joined #evergreen |
| 13:15 |
jeff |
one thing that can lead to stuck reports like that is if clark loses connection to the db. |
| 13:16 |
|
mdriscoll joined #evergreen |
| 13:16 |
jeff |
no amount of try / otherwise will help there :-) |
| 13:17 |
Bmagic |
jeff: yeah - my guess is we killed clark not realizing that it was still working on a long winded report |
| 13:17 |
Dyrcona |
Heh. I was just thinking that a staleness check could be added to Clark, to ignore really old incomplete reports. |
| 13:18 |
Bmagic |
it's working on those two now... still going, I'm curious - going to dig into those and see what sort of query is running |
| 13:18 |
Dyrcona |
Bitcoin has a check that if a packet's timestamp is off by ten minutes it throws it away. |
| 13:18 |
Bmagic |
jeff: 2 were from 2012, 2 were from yesterday |
| 13:18 |
jeff |
Bmagic: ah! i misunderstood. |
| 13:18 |
Dyrcona |
The comment says, "Came by in a flying delorean." ;) |
| 13:19 |
Bmagic |
jeff: I didn't diverge the details. I removed the rows from 2012, and updated the other two rows to start_time=null |
| 13:21 |
Dyrcona |
So, I wonder if the 2 from 2012 really were a problem? Two from yesterday definitely would be. |
| 13:21 |
Dyrcona |
Although, maybe once the number hit four, the -c 4 kicks in, and no new ones run at all. |
| 13:21 |
Dyrcona |
Must be it. |
| 13:22 |
jeff |
right. |
| 13:29 |
Bmagic |
yeah, there is code in clark_kent.pl that querys "select count(*) FROM reporter.schedule WHERE start_time IS NOT NULL AND complete_time IS NULL; " |
| 13:30 |
Bmagic |
and then an if statement to check if the allocated run slots total is less than the return from that query |
| 13:30 |
jeff |
right. |
| 14:00 |
|
maryj joined #evergreen |
| 14:19 |
|
ericar joined #evergreen |
| 14:58 |
|
maryj_ joined #evergreen |
| 15:02 |
|
mmorgan left #evergreen |
| 15:05 |
|
Stompro joined #evergreen |
| 15:10 |
csharp |
@quote add < kmlussier> NOBLE, the place where you can have unlimited coffee and Located URI's that appear in a consortium-wide search. :) |
| 15:10 |
pinesol_green |
csharp: The operation succeeded. Quote #139 added. |
| 15:11 |
Dyrcona |
@quote random |
| 15:11 |
pinesol_green |
Dyrcona: Quote #123: "<berick> gmcharlt: what's a few rootkits between friends?" (added by gmcharlt at 04:25 PM, August 05, 2015) |
| 15:11 |
csharp |
@karma snow |
| 15:11 |
pinesol_green |
csharp: snow has neutral karma. |
| 15:15 |
Dyrcona |
@roulette |
| 15:15 |
pinesol_green |
Dyrcona: *click* |
| 15:16 |
pinesol_green |
[evergreen|Dan Wells] LP#1526547 Re-broaden backdate note setting - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=aa4d367> |
| 15:16 |
pinesol_green |
[evergreen|Dan Wells] LP#1526547 Improve note setting for backdates - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=940d1ac> |
| 15:16 |
pinesol_green |
[evergreen|Dan Wells] LP#1526547 Prevent bogus notes when adjusting lost/lod overdues - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=98477d3> |
| 15:18 |
kmlussier2 |
snow-- |
| 15:31 |
|
jvwoolf1 left #evergreen |
| 16:08 |
berick |
kmlussier: re: bug 1474051 did you confirm your org unit table had more values before applying the patch? that almost sounds like an install without the seed/test data installed. |
| 16:08 |
pinesol_green |
Launchpad bug 1474051 in Evergreen "Avoid storing partial credit card payment info" [Wishlist,Triaged] https://launchpad.net/bugs/1474051 |
| 16:09 |
kmlussier |
berick: I'm using tsbere's script that merges the patch before the install. But I've done other installs today on the same machine without any problem. There's also other seed data in the tables. |
| 16:12 |
berick |
kmlussier: grr, I see the problem. base schema is missing a "," |
| 16:12 |
berick |
sorry for the runaround. pushing fix.. |
| 16:14 |
kmlussier |
Those damn pesky commas! |
| 16:14 |
berick |
fwiw, tracking everying in sqitch (or at least not having 2 copies of everyting) would really help w/ this kind of stuff. |
| 16:16 |
* berick |
builds a new db from fixed files to make sure it builds |
| 16:54 |
dbs |
sqitch! |
| 17:08 |
|
mdriscoll left #evergreen |
| 17:35 |
|
dcook joined #evergreen |
| 18:04 |
|
rlefaive joined #evergreen |
| 18:26 |
|
hopkinsju joined #evergreen |
| 18:26 |
|
Bmagic joined #evergreen |
| 18:26 |
|
dluch joined #evergreen |
| 18:51 |
jwoodard |
@8ball Earl Grey or Darjeeling? |
| 18:51 |
pinesol_green |
jwoodard: Fire BAD! Reading GOOD! |
| 18:51 |
jwoodard |
thanks for the insight pinesol_green..... |
| 19:19 |
kmlussier |
@decide Earl Gray or Darjeeling? |
| 19:19 |
pinesol_green |
kmlussier: go with Darjeeling? |
| 19:19 |
kmlussier |
Guess I didn't need the question mark |
| 20:46 |
bshum |
Count it kmlussier |
| 20:46 |
bshum |
parts++ |
| 20:46 |
kmlussier |
bshum: That was my goal! |
| 20:46 |
kmlussier |
bshum++ |
| 20:46 |
bshum |
kmlussier++ for making parts less sucky for next release |
| 20:46 |
pinesol_green |
[evergreen|Kathy Lussier] lp1422802 Release notes entry - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ac60ad8> |
| 20:46 |
pinesol_green |
[evergreen|Kathy Lussier] lp1422802: Improve visibility of parts on Place Holds screen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cb51783> |
| 21:08 |
|
dcook__ joined #evergreen |
| 22:45 |
|
dcook joined #evergreen |
| 23:36 |
|
kmlussier joined #evergreen |
| 23:36 |
|
mceraso joined #evergreen |
| 23:36 |
|
bshum joined #evergreen |
| 23:38 |
|
bmills joined #evergreen |
