| Time |
Nick |
Message |
| 00:00 |
|
gsams joined #evergreen |
| 04:21 |
|
gsams_ joined #evergreen |
| 05:18 |
|
jwl joined #evergreen |
| 05:23 |
jwl |
We are starting a new school and have many books that have been contributed. We plan on using evergreen. I want to generate a file with the book info that will eventually be imported into evergreen. What's the simplest way to do that? |
| 05:23 |
jwl |
I'm not a librarian, just a programmer/developer who's helping with IT. |
| 05:25 |
jwl |
It's all volunteer labor. We don't have a computer system/network set up so I want to get started generating the information for the catalog immediately. |
| 07:00 |
|
mrpeters joined #evergreen |
| 07:10 |
|
agoben joined #evergreen |
| 07:17 |
|
collum joined #evergreen |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 07:32 |
|
ericar joined #evergreen |
| 07:36 |
|
tarac joined #evergreen |
| 07:36 |
|
TARA joined #evergreen |
| 08:03 |
csharp |
jwl: you or the volunteer staff will have to create or import MARC records for each of the books/items - both creation and import can be done within Evergreen |
| 08:19 |
|
JBoyer joined #evergreen |
| 08:32 |
|
rlefaive joined #evergreen |
| 08:32 |
|
Christineb joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:53 |
|
Dyrcona joined #evergreen |
| 09:00 |
|
maryj joined #evergreen |
| 09:04 |
StomproJ |
berick++ I really like the "Skip_viable" feature in the hold targeter you released. I think that will help us out. |
| 09:06 |
|
bos20k joined #evergreen |
| 10:02 |
berick |
StomproJ: cool. thanks for taking a look at it. |
| 10:25 |
miker |
berick++ # plus a couple thoughts... |
| 10:26 |
berick |
miker: i'm all ears |
| 10:26 |
miker |
berick: it doesn't look like format filtering for M-type holds is handled |
| 10:26 |
berick |
ah, ok |
| 10:27 |
miker |
and I think that there are cases where the unfilled holds table isn't updated, such as when the same copy is being reused, and in skip-viable mode (which is probably intentional based on the description, but I think should require stronger language regarding its use) |
| 10:29 |
miker |
and I'll have to look more closely at the old code, but I believe the replacement for the "copy tree" stuff (the one huge query) may not return the same set in some cases |
| 10:29 |
miker |
note, that's just from reading the code in gitweb ... I plan to look closer and trace it |
| 10:30 |
berick |
miker++ |
| 10:30 |
berick |
not logging unfulfilled def. intentional in skip-viable mode |
| 10:30 |
tsbere |
berick: I can confirm that the "# TODO: Should this include 'R' holds? ..." comment regarding parts should be a "no, it should not be included there". F and R should be treated identically at the targeter level. |
| 10:31 |
berick |
tsbere: thanks! I'll remove that comment |
| 10:32 |
* tsbere |
wonders how difficult it would be to do the "potential copies" dance once for multiple holds (same type/target/pickup location/selection ou/selection depth?) to speed some things up... |
| 10:35 |
csharp |
berick++ |
| 10:35 |
csharp |
we're gonna start testing that on a test server in the next week or so |
| 10:37 |
berick |
tsbere: yeah i could see that.. have the batch mode group by target+type and churn over the same initial copy set (minus any that get targeted in the process). |
| 10:37 |
berick |
csharp++ |
| 10:38 |
tsbere |
berick: Well, you would need the ones targeted in the process for potentials still, and the selection ou/depth would need to be included as well. |
| 10:38 |
berick |
yeah, true |
| 10:39 |
* berick |
will look at the metabib format stuff today |
| 10:39 |
tsbere |
berick: I suppose I should mention "for M holds, the metabib format may need to match too" ;) |
| 10:40 |
miker |
berick: am I correct that most of the speedup comes from the hold map batching? |
| 10:43 |
miker |
fwiw, I'm not a big fan of including calls to this module all over the backend, or potentially calling from the front end. is there a reason not to surface the implementation as an opensrf method? the circ app seems like a good place. and then in could be parallelized to get even more speed than the implementation speedup alone |
| 10:43 |
berick |
miker: not sure where all of the speed up comes from. I just saw that as a win. it's also caching more org unit settings. there were a few still slipping through that had to be checked on each hold in the existing code. |
| 10:44 |
miker |
the caching could be done at the session level to retain that, re YAOUS lookup and an opensrf method |
| 10:44 |
berick |
miker: i was thinking maybe giving it its own service... (?) I didn't want to put it into circ because that would make it public. |
| 10:45 |
miker |
service++ |
| 10:45 |
csharp |
speedup++ |
| 10:45 |
miker |
a perm-protected public version (that calls the service) seems useful |
| 10:45 |
csharp |
hold placement speed is probably our biggest single biggest complaint from staff nowadays |
| 10:46 |
csharp |
argh - too many biggests! |
| 10:46 |
miker |
csharp: this won't change placement speed. just targetting, which happens after placement, and out of band |
| 10:46 |
berick |
to be fair, when targeting is needed inline (e.g. checkin), I like direct calls (no service), since using a service in that case only adds overhead. |
| 10:47 |
berick |
but a service would def. come in hand in other cases (parallal processing, fire-and-forget situations) |
| 10:47 |
* tsbere |
has previously thought about rigging the hold rules DB functions to accept multiple copy ids, returning on the first successful or after they *all* failed, to avoid repeated calls to the DB during placement |
| 10:50 |
miker |
berick: well, if we're talking about going from 2s to .5s, then the 20ms for an opensrf call seems less important. and it means not having to touch multiple call sites when the API changes, and (for me, at least) it means only having to restart the authoritative home of the code at patch propogation time, instead of going and finding all the various services that use the code internally |
| 10:51 |
* miker |
glances sidelong at the penalty inline code) |
| 10:52 |
berick |
miker: yeah, i can see that |
| 10:53 |
miker |
(and, today, perl opensrf overhead is more like 5-7ms in our env) |
| 10:53 |
miker |
(c is 2-4ms) |
| 10:54 |
berick |
so i'll add open-ils.hold-targeter to today's todo |
| 11:01 |
|
bmills joined #evergreen |
| 11:02 |
|
jvwoolf joined #evergreen |
| 11:04 |
csharp |
miker: oh :-( |
| 11:04 |
|
bmills1 joined #evergreen |
| 11:12 |
jwl |
csharp: Thanks, I figured that but I was hoping to generate the data before we get Evergreen running. Maybe with a flat file or a csv file and write a simple script to generate MARC records.. |
| 11:12 |
miker |
berick++ |
| 11:14 |
* jeff |
does a git fetch --all on something other than his "usual" working copy |
| 11:14 |
jeff |
"oh, that branch looks interesting..." |
| 11:14 |
jeff |
"oh. my branch." |
| 11:14 |
jeff |
(already merged to master and released in 2.10) |
| 11:15 |
* JBoyer |
has run into that. |
| 11:16 |
JBoyer |
Usually around upgrade time though. (WHY U NO WORK? Oh, already did that a while back...) |
| 11:18 |
jeff |
oh, in terms of trying to apply a local patch/branch? :-) |
| 11:20 |
tsbere |
I love it when I conflict with my own code in a customization branch (customized patch in branch, uncustomized made it into master...) |
| 11:24 |
JBoyer |
jeff, Sometimes, more excitingly when testing db upgrades. |
| 11:31 |
Dyrcona |
I love it when two customizations conflict with each other...... |
| 11:31 |
csharp |
jwl: there are probably pre-built tools out there, but you might look into MARC::Record if you want to write perl scripts around creating/manipulating MARC |
| 11:31 |
Dyrcona |
Even after rebasing.... |
| 11:31 |
|
StJoesCollege joined #evergreen |
| 11:32 |
StJoesCollege |
good morning |
| 11:32 |
graced |
good morning! |
| 11:33 |
StJoesCollege |
We went live with evergreen a few months back and we are having some problems getting circulation notices to work (overdues etc...) is there something on the server side we need to enable for this to generate? |
| 11:35 |
* graced |
does not dabble in action triggers for notices |
| 11:36 |
Bmagic |
StJoesCollege: yes, the action trigger stuff requires a server side cron job |
| 11:36 |
tsbere |
StJoesCollege: Do you have an email system in place on the servers? Are you running the example cron jobs? Are the A/T event definitions enabled? |
| 11:37 |
StJoesCollege |
we do have an email system |
| 11:37 |
StJoesCollege |
it works, ive tested the email from inside the evergreen client. |
| 11:38 |
|
brahmina joined #evergreen |
| 11:38 |
Bmagic |
StJoesCollege: Generally you designate one of your app servers to do the work. http://wiki.evergreen-ils.org/doku.php?id=evergreen-user:action_trigger |
| 11:39 |
dbwells |
StJoesCollege: Here is some more polished documenation for notices, though perhaps less complete: http://en.flossmanuals.net/evergreen-in-action/sending-gentle-reminders-to-your-users/ |
| 11:40 |
StJoesCollege |
thanks, ill take a look at the docs, this should be most helpful |
| 11:40 |
dbwells |
StJoesCollege: You are probably missing the action_trigger_runner.pl stuff, i.e. the stuff you want in cron job. |
| 11:40 |
StJoesCollege |
Ill take a look quick |
| 11:41 |
tsbere |
StJoesCollege: I would also check on action_trigger_filters.json |
| 11:41 |
tsbere |
There are defaults for when that isn't there, but they cover less than what that will trigger |
| 11:42 |
StJoesCollege |
we have 'action_trigger_runner.pl --osrf-config $SRF_CORE --run-pending' in the cron |
| 11:43 |
StJoesCollege |
and --process-hooks --granularity |
| 11:48 |
dbwells |
StJoesCollege: circ notices need the "checkout.due" hook to be processed |
| 11:48 |
dbwells |
That can come from a filter file like tsbere mentioned, or by adding e.g. "--hooks checkout.due" to the action_trigger_runner.pl command. |
| 11:49 |
dbwells |
StJoesCollege: I believe the default install will have an inactive filter file at /openils/conf/action_trigger_filters.json.example |
| 11:50 |
dbwells |
You can rename that without the ".example" to get the out-of-the-box default filters. |
| 11:50 |
StJoesCollege |
@dbwells thanks Ill give it a try |
| 11:50 |
pinesol_green |
StJoesCollege: did you finish your beer? |
| 11:51 |
csharp |
@quote random |
| 11:51 |
pinesol_green |
csharp: Quote #85: "< bshum> *Everything* is awesome." (added by csharp at 09:29 AM, May 27, 2014) |
| 11:51 |
StJoesCollege |
@pinesol_green mmmm beeer :) |
| 11:51 |
pinesol_green |
StJoesCollege: Have you tried taking it apart and putting it back together again? |
| 11:54 |
Dyrcona |
StJoesCollege: Using @ in front of something tells the bot to execute a command. |
| 11:55 |
Dyrcona |
If you want to address someone, just user their nick. |
| 11:55 |
Dyrcona |
s/user/use/ |
| 11:55 |
Dyrcona |
;/ |
| 12:02 |
Dyrcona |
I'm taking myself and my typos across the street for some lunch. BBIAB. |
| 12:14 |
|
ericar joined #evergreen |
| 12:58 |
|
jihpringle joined #evergreen |
| 13:03 |
|
jeff_ joined #evergreen |
| 13:07 |
|
maryj_ joined #evergreen |
| 13:09 |
|
maryj__ joined #evergreen |
| 13:35 |
|
tarac joined #evergreen |
| 13:37 |
|
ericar joined #evergreen |
| 14:42 |
|
gsams joined #evergreen |
| 15:01 |
|
maryj_ joined #evergreen |
| 15:06 |
|
maryj joined #evergreen |
| 15:07 |
|
maryj__ joined #evergreen |
| 15:08 |
|
maryj___ joined #evergreen |
| 15:09 |
|
bmills joined #evergreen |
| 15:13 |
|
maryj joined #evergreen |
| 15:15 |
|
maryj_ joined #evergreen |
| 15:19 |
|
maryj joined #evergreen |
| 15:19 |
bmills |
has anyone had difficulty with getting results for their title searches that contain apostrophes? e.g. “i’ve got your number” and “all these things i’ve done”? i’m not sure if this is a new thing for us, but those titles are getting pulled out of the search results. however, a title search for “all these things i ve done” retrieves the correct results. |
| 15:19 |
bmills |
just wondering if anyone on the channel had hints for starting an investigation... |
| 15:20 |
tsbere |
bmills: Normalization of those is annoying. |
| 15:21 |
tsbere |
bmills: "i ve got your number" or "ive got your number" working will show you if they are being turned into spaces or just removed in the background, the one that doesn't work (provided that one does) being what is happening |
| 15:21 |
|
maryj__ joined #evergreen |
| 15:22 |
Dyrcona |
tsbere: I'm guessing spaced given something that bmills already said. |
| 15:22 |
Dyrcona |
MVLC's are working with apostrophes. |
| 15:22 |
bmills |
tsbere: "ive got your number" fails to return anything but "i ve got your number" brings in the correct titles |
| 15:22 |
* tsbere |
missed that part of what bills said |
| 15:24 |
tsbere |
bmills: I do wonder why you are normalizing to space in indexing but (apparently) removing in searching. I don't have enough search stuff in my head right now without digging to help all that directly, though. |
| 15:24 |
jeff |
at times those normalizations were out of sync / broken. |
| 15:25 |
bmills |
tsbere: not sure either. i wasn't aware of this until a cataloger brought it to my attention. would like to think it hasn't been going on for a while.. |
| 15:25 |
jeff |
it might be a case of having an outdated field def. |
| 15:25 |
tsbere |
bmills: You may need a mass re-index. Potentially after checking your field defs. |
| 15:28 |
mmorgan |
bmills: By default, the normalizers active in Evergreen change apostrophes into spaces. |
| 15:28 |
bmills |
some example bits http://pastebin.com/7PkNGMth for this guy: http://catalog.sage.eou.edu/eg/opac/record/1178516 |
| 15:30 |
* mmorgan |
looks for more info |
| 15:31 |
bmills |
tsbere: was hoping to not have to do a mass re-index, but that could be it. restored our db into a test vm and the normalization issues don't seem to be occurring there.. |
| 15:31 |
* jeff |
raises an eyebrow |
| 15:32 |
* tsbere |
has also raised an eyebrow as he didn't think a restored DB would be re-indexed, so the normalization issues should still be there |
| 15:33 |
bmills |
maybe i'm mistaken, but it was from a pg_dump of the database. don't the indexes get recreated in that process? |
| 15:34 |
jeff |
bmills: do you have more than one result for this query? SELECT DISTINCT routine_schema, routine_name FROM information_schema.routines WHERE routine_name = 'search_normalize'; |
| 15:35 |
bmills |
jeff: no, just the one from public |
| 15:35 |
jeff |
good. :-) |
| 15:35 |
jeff |
on both the restored db and on production? |
| 15:36 |
bmills |
jeff: just checked. only the one there too |
| 15:37 |
jeff |
good! |
| 15:40 |
mmorgan |
We plan to change our production database to use NACO normalization rather than the default Search normalization with our next upgrade. We've been testing it on our training system and like what we're seeing for the most part. |
| 15:41 |
mmorgan |
On our training server, "I've got our number" gets hits. |
| 15:41 |
bmills |
mmorgan: thanks for looking! we did an in place upgrade to 9.3 not too long ago, wondering if something might happened there.. |
| 15:42 |
mmorgan |
bmills: It's not a postgres thing, but an Evergreen config. |
| 15:44 |
bmills |
mmorgan: i've done some searches on other evergreen catalogs that i'm assuming are using the default search_normalize and the "i've got your number" and "all these things i've done" titles seem to pull up ok in title searches. so i think it's us being borked somewhere |
| 15:45 |
jeff |
bmills: same results with title and keyword searches? |
| 15:45 |
jeff |
i suppose i could test that part myself. |
| 15:46 |
bmills |
jeff: keyword brings up those title just fine |
| 15:47 |
Bmagic |
same here "I've got your number" works |
| 15:54 |
bmills |
jeff++ mmorgan++ tsbere++ thanks! i'll keep at it |
| 15:54 |
mmorgan |
indexing/searching is complicated :-/ |
| 16:16 |
|
jlitrell joined #evergreen |
| 16:18 |
|
jvwoolf left #evergreen |
| 17:03 |
|
mmorgan left #evergreen |
| 20:34 |
|
dcook joined #evergreen |
| 21:34 |
|
dbwells joined #evergreen |
| 22:35 |
|
bmills left #evergreen |
