| Time |
Nick |
Message |
| 00:09 |
jeff |
and i believe bug 1187035 completes the "remove cruft!" trifecta. i'd push it myself were it not for that pesky third commit lacking signoff. :-) |
| 00:09 |
jeff |
pinesol_green: you there? |
| 00:09 |
jeff |
ah well. that would be bug 1187035, "Remove obsolete OpenILS::Utils::Editor" https://bugs.launchpad.net/evergreen/+bug/1187035 |
| 00:09 |
pinesol_green |
Launchpad bug 1187035 in Evergreen "Remove obsolete OpenILS::Utils::Editor" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1187035 |
| 00:09 |
pinesol_green |
jeff: I see nothing, I know nothing! |
| 00:20 |
jeff |
laggy bot! |
| 00:29 |
bshum |
jeff: Thanks, and here I almost forgot what cold and snow was like. |
| 00:32 |
* bshum |
is still glad to be home though. |
| 01:00 |
jeff |
yeah. home is a good feeling. |
| 01:18 |
* jeff |
eyeballs bug 1184885 |
| 01:18 |
pinesol_green |
Launchpad bug 1184885 in Evergreen "Acq Search dropdown class name abbreviations are untranslatable" (affected: 2, heat: 10) [Medium,Triaged] https://launchpad.net/bugs/1184885 - Assigned to Jeff Godin (jgodin) |
| 01:23 |
|
zerick joined #evergreen |
| 01:31 |
bshum |
jeff: It looked okay to me. I just haven't gotten around to checking the initials. |
| 02:09 |
jeff |
well that's odd. i'm not seeing a signoff with git cherry-pick -s hash |
| 02:09 |
jeff |
i mean, I can add it manually, and I'm re-wording the commit message anyway, but still... weird. |
| 02:50 |
* jeff |
wonders why acq::lineitem's abbreviation is "jub" |
| 02:50 |
jeff |
perhaps all the good abbreviations were taken. |
| 02:59 |
pinesol_green |
[evergreen|Pasi Kallinen] LP#1184885 ACQ: i18n for search abbreviations - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=796ed67> |
| 03:04 |
paxed |
jeff: jubjub bird! |
| 03:09 |
jeff |
heh |
| 03:10 |
jeff |
@who is the frumious Bandersnatch |
| 03:10 |
pinesol_green |
jeff: http://wonder-tonic.com/geocitiesizer/content.php?theme=2&music=6&url=evergreen-ils.org |
| 03:10 |
jeff |
bah. |
| 03:31 |
pinesol_green |
[evergreen|Jason Etheridge] LP#1272575 Use getElementById over querySelector - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1fefe2c> |
| 07:00 |
|
timf joined #evergreen |
| 08:01 |
|
akilsdonk joined #evergreen |
| 08:10 |
|
collum joined #evergreen |
| 08:20 |
|
rjackson-isl joined #evergreen |
| 08:24 |
|
jboyer-laptaupe joined #evergreen |
| 08:28 |
csharp |
@quote random |
| 08:28 |
pinesol_green |
csharp: Quote #25: "<Dyrcona> how about we rename it to DONT_README" (added by gmcharlt at 12:00 PM, May 15, 2012) |
| 08:33 |
|
kbeswick joined #evergreen |
| 08:35 |
berick |
@later tell jeff "jub" == Jacked-Up Bib |
| 08:35 |
pinesol_green |
berick: The operation succeeded. |
| 08:38 |
|
Shae joined #evergreen |
| 08:49 |
|
mmorgan joined #evergreen |
| 08:58 |
jeff |
i was trying to find a JBOD-like meaning in there :-) |
| 08:59 |
berick |
jeff: fyi, signing off on bug #1187035, but i'm about to push another commit |
| 08:59 |
pinesol_green |
Launchpad bug 1187035 in Evergreen "Remove obsolete OpenILS::Utils::Editor" (affected: 1, heat: 6) [Wishlist,In progress] https://launchpad.net/bugs/1187035 - Assigned to Bill Erickson (erickson-esilibrary) |
| 09:03 |
jeff |
don't tell me that in another typo i recommended removing open-ils.circ or something. :-) |
| 09:04 |
dbs |
jeff++ # cruft-killer |
| 09:07 |
berick |
jeff: heh, no, not a typo. |
| 09:07 |
berick |
ticket updated |
| 09:07 |
berick |
this ticket wins the "first time make livcheck found a bug" award (for me) |
| 09:08 |
berick |
ironically, the code in question will almost certainly be replaced by direct pcrud calls in the future (if it hasn't already). |
| 09:09 |
dbs |
"make liver-check" might be useful during the conference |
| 09:10 |
jeff |
berick++ |
| 09:10 |
jeff |
tests++ |
| 09:10 |
dbs |
Do we have a documented set of tests / make targets to run for development & signoff? |
| 09:10 |
dbs |
make check && make livecheck? |
| 09:10 |
berick |
dbs: why look for something you don't want to find? |
| 09:11 |
* dbs |
can add that to http://wiki.evergreen-ils.org/doku.php?id=dev:signoff_review_checklist |
| 09:11 |
berick |
that was in response to liver-check, not signoff tests |
| 09:11 |
berick |
dbs++ |
| 09:11 |
berick |
jeff++ |
| 09:13 |
dbs |
added. not sure if anyone is actually looking at the review signoff list but occasionally people find the wiki :) |
| 09:14 |
jeff |
speaking of make check, does everyone else get a handful of warnings in metabib.pm? I dug just enough to see that the fix is probably simple and probably-simple (two different warnings, but one repeated several times), and confirmed that they weren't introduced by anything i was signing off on, but did not open a bug. |
| 09:15 |
berick |
jeff: yes, i get the warnings. |
| 09:15 |
* berick |
will gladly sign off if a fix is pushed |
| 09:15 |
jeff |
that checklist would have helped the other day when i forgot to bump the upgrade id in 002.schema.config.sql |
| 09:23 |
|
mrpeters joined #evergreen |
| 09:37 |
|
RoganH joined #evergreen |
| 09:42 |
|
yboston joined #evergreen |
| 09:49 |
jeff |
oh, i should start services before running make livecheck :P |
| 09:51 |
jeff |
and have the expected admin password... |
| 09:51 |
jeff |
i believe i've only run these from the uberscript |
| 10:04 |
jeff |
berick++ tests clean, pushed to master! |
| 10:05 |
pinesol_green |
[evergreen|Jeff Godin] LP#1187035 Remove OpenILS::Utils::Editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0199ecd> |
| 10:05 |
pinesol_green |
[evergreen|Bill Erickson] LP#1187035 Remove OpenILS::Utils::Editor part 2. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb222e7> |
| 10:05 |
pinesol_green |
[evergreen|Jeff Godin] LP#1187035 Remove OpenILS::Utils::Editor part 3. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8eda1c2> |
| 10:05 |
pinesol_green |
[evergreen|Bill Erickson] LP#1187035 Remove OpenILS::Utils::Editor part 4. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7e45929> |
| 10:06 |
jeff |
heh. rel_2_5 branch has 110729 lines in .pm files, master has 108632. (just with a very simple find . -name \*.pm -print0 | xargs -0 wc -l ) |
| 10:07 |
jeff |
and for similar on .txt files in docs/, we go from 19758 to 20116 lines. |
| 10:07 |
|
Bmagic joined #evergreen |
| 10:07 |
jeff |
these are mostly meaningless metrics, but can sometimes be interesting regardless. |
| 10:14 |
|
krvmga joined #evergreen |
| 10:15 |
krvmga |
at http://bark.cwmars.org using IE9: i've had a number of reports that the search location dropdown will not work. no dropdown. if dropdown, no scrollbar on right side. has anyone else had reports like this? |
| 10:16 |
krvmga |
i am not able to duplicate the problem with ietester |
| 10:18 |
berick |
wonder if it's the same as bug 1002971 |
| 10:18 |
pinesol_green |
Launchpad bug 1002971 in Evergreen "tpac: library names are cut off in library selector when using IE" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1002971 |
| 10:19 |
bshum |
berick: Well that bug notes that it doesn't affect IE9 in my testing. |
| 10:20 |
berick |
ah |
| 10:20 |
bshum |
My first kneejerk reaction for krvmga is to check that one of your bricks isn't malfunctioning with a bad dropdown. |
| 10:22 |
bshum |
krvmga: Also, for those of us who don't follow religiously, it helps to know what version of Evergreen you're on :) |
| 10:23 |
* bshum |
ponders something like IE compatibility mode doing horrible things to TPAC though. |
| 10:30 |
krvmga |
bshum: yes sorry i should have said 2.4 |
| 10:30 |
krvmga |
berick: i don't know if it's related to that launchpad report. in ietester the library names are still cut off in the older versions of IE |
| 10:39 |
|
Polonel joined #evergreen |
| 10:41 |
|
Dyrcona joined #evergreen |
| 10:48 |
|
dluch joined #evergreen |
| 10:52 |
|
mcooper joined #evergreen |
| 11:13 |
|
jwoodard joined #evergreen |
| 11:31 |
|
dluch joined #evergreen |
| 11:35 |
|
dluch2 joined #evergreen |
| 11:40 |
fparks_ |
eeevil: are you around? |
| 11:42 |
|
dluch joined #evergreen |
| 11:42 |
eeevil |
fparks_: I don't have my full attention here, but I'll respond as I can |
| 11:46 |
fparks_ |
I have implemented what you discribed in LP, and I is working for the english keywords. But when I switch the language to fr-CA I am still getting the english keywords. |
| 11:46 |
fparks_ |
eeevil: do you think there is any IDL configuration I could have missed? |
| 11:50 |
eeevil |
fparks_: if the idl has oils_persist:i18n="true" for the string column, that will be it. turn on full statement logging for the db and see what's being requested to confirm it's making all the SELECTs you expect |
| 11:52 |
|
jboyer_laptaupe joined #evergreen |
| 11:57 |
dbwells |
grabbing 0858 |
| 11:58 |
csharp |
you shouldn't have to restart more than apache to get NoveList loaded right? I haven't restarted opensrf because I was assuming it was all apache-level |
| 11:59 |
bshum |
csharp: Assuming you're using the apache variables, then yes, that's all I would expect to be needed too. |
| 11:59 |
csharp |
okay - we think it's disabled on the NoveList end, but wanted to make sure |
| 11:59 |
csharp |
bshum: thanks ;-) |
| 12:00 |
* bshum |
always blames the vendor first these days :) |
| 12:00 |
* csharp |
wishes his libraries felt the same way ;-) |
| 12:01 |
bshum |
Actually, you solved your JS wackiness right? |
| 12:01 |
csharp |
er... I don't think I came back to it actually |
| 12:01 |
csharp |
the last month has been screwy |
| 12:01 |
jeff |
look for a comment "Load novelist content" on your record pages -- and check your browser console. |
| 12:03 |
jeff |
and novelist might be buried under the "Awards" expando. |
| 12:03 |
|
snowkitteh_ joined #evergreen |
| 12:03 |
|
BigRig joined #evergreen |
| 12:06 |
|
bitgeeky joined #evergreen |
| 12:07 |
bshum |
I think it is. |
| 12:07 |
csharp |
yeah - I'm just seeing "Loading..." |
| 12:07 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] LP#1272074 Context menus suggesting values for marc fixed field editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7e12a0c> |
| 12:07 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] LP#1272074 Physical Characteristics Wizard for the MARC Editor - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b119022> |
| 12:07 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] LP#1272074 Fix faulty physical characteristics seed data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=35cca91> |
| 12:07 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] LP#1272074 Release notes (with pictures!) of fixed fields MARC editor enhancements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df26f9e> |
| 12:07 |
pinesol_green |
[evergreen|Dan Wells] Stamping 0858: Fixed field enhancements - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3eee581> |
| 12:08 |
csharp |
bshum: I think you're onto it though... gonna get my want_dojo on ;-) |
| 12:08 |
bshum |
csharp: I had that sinking feeling |
| 12:10 |
dbs |
Ah, good old Dojo! |
| 12:10 |
jeff |
want_dojo should be set by the templates based on the novelist vars being set. |
| 12:10 |
jeff |
though perhaps you've overriding or have outdated locally-overriden templates. |
| 12:11 |
jeff |
senator++ dbwells++ fixed field improvements |
| 12:11 |
bshum |
Well if you disable autosuggest, it tends to kill the want_dojo variable. |
| 12:11 |
bshum |
And if you don't enable google books, it doesn't come on either |
| 12:11 |
bshum |
There's a couple places where if you selectively turn off different features, that variable doesn't get turned on |
| 12:11 |
bshum |
And things... malfunction |
| 12:12 |
bshum |
That said, I think csharp's catalog has it working better now (if the copy location picker is any indication in his advanced search) |
| 12:13 |
jeff |
in rel_2_5 and master, want_dojo is only modified in opac/parts/header.tt2 |
| 12:13 |
jeff |
it is 0 by default, but set to 1 if any of the following are enabled: autosuggest, google books, novelist |
| 12:14 |
jeff |
so as long as ENV.OILS_NOVELIST_URL is seen to be set by the templates, want_dojo = 1 |
| 12:14 |
bshum |
Then maybe he's okay. |
| 12:14 |
bshum |
You know actually now that you mention it jeff... I remember giving someone a hard time during the novelist rewrites to make sure it got tied into dojo stuff |
| 12:14 |
bshum |
Like two hackaways ago |
| 12:15 |
jeff |
I believe there was a novelist sponsor/participant at the first hack-a-way, year-before-last at the ESI offices. |
| 12:16 |
gmcharlt |
there was |
| 12:23 |
pinesol_green |
[evergreen|Lebbeous Fogle-Weekley] LP#1272074 Physical Characteristics Wizard for the MARC Editor (Part II) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3009666> |
| 12:25 |
bshum |
@later tell montgoc1 SPACESHIP!!! |
| 12:25 |
pinesol_green |
bshum: The operation succeeded. |
| 12:33 |
csharp |
jeff: bshum: yeah, since the novelist url is set, looks like that turns on dojo |
| 12:33 |
* csharp |
changes varible name to sorta_want_dojo :-/ |
| 12:37 |
csharp |
bshum++ # detective work around our JS issue |
| 12:43 |
dbs |
will_use_dojo_if_i_must |
| 12:45 |
* eeevil |
grabs 0859 |
| 12:50 |
pinesol_green |
[evergreen|Ben Shum] Add granular settings for requiring staff initials for notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4583dd5> |
| 12:50 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade for Granular Staff Initials settings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6d750a0> |
| 12:50 |
fparks_ |
eeevil: It seems to be receaving the locale en-US event though I have the location set to fr-CA |
| 12:51 |
fparks_ |
SELECT "es".purpose, oils_i18n_xlate('config.strings', 'es', 'string', 'purpose', "es".purpose::TEXT, 'en-US') AS "string" FROM config.strings AS "es" WHERE "es".purpose like 'bool-op-%'; |
| 12:52 |
|
jboyer_laptaupe joined #evergreen |
| 12:52 |
eeevil |
fparks_: are you saying that that's the only one you're seeing, or that you've isolated the log entries that belong specifically to the request that was in the fr-CA locale? (I ask because if it's broken for your new code, it's broken ... everywhere. and we've had no such reports yet) |
| 12:54 |
fparks_ |
eeevil: I have only been looking specificly for that request |
| 12:55 |
fparks_ |
eeevil: I do see the fr-CA locale poping up in other parts of the log |
| 12:56 |
* eeevil |
grabs 0860 |
| 12:56 |
paxed |
fun for the whole consortium! |
| 13:02 |
pinesol_green |
[evergreen|Bill Erickson] DB patch supersede/deprecate logic repairs; unit tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b7f0b1d> |
| 13:02 |
pinesol_green |
[evergreen|Mike Rylander] Stamping upgrade script for supsersede/deprecate logic fixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4be7952> |
| 13:04 |
jeff |
29 fix committed |
| 13:05 |
eeevil |
fparks_: without seeing the code that's failing, I couldn't say why it's not picking up the in-use locale while other parts of the system seem to be, based on what you say about the logs |
| 13:10 |
eeevil |
I'd like to get more eyes on this chunk of plpgsql, because either I'm misunderstanding it, or it's doint the wrong thing: |
| 13:10 |
eeevil |
+ v_depth := coalesce( |
| 13:10 |
eeevil |
+ p_depth, |
| 13:10 |
eeevil |
+ ( |
| 13:10 |
eeevil |
+ SELECT depth |
| 13:10 |
eeevil |
+ FROM actor.org_unit_type aout |
| 13:11 |
eeevil |
+ INNER JOIN actor.org_unit ou ON ou_type = aout.id |
| 13:11 |
eeevil |
+ WHERE ou.id = p_ouid |
| 13:11 |
eeevil |
+ ), |
| 13:11 |
eeevil |
+ p_pref_lib |
| 13:11 |
eeevil |
+ ); |
| 13:11 |
eeevil |
(sorry for the blob ... should have used a pastebot) |
| 13:12 |
eeevil |
p_depth is an aout.depth (nullable parameter), p_ouid is a context org (not nullable), p_pref_lib is an aou.id and is nullable |
| 13:13 |
eeevil |
my question is: why is p_pref_lib in that coalesce list? |
| 13:16 |
eeevil |
if "no reason", then I want to try to turn 3bf9f947a57e3621724c9a22441a47e9b9cf682d back into SQL and merge in the MR holds and Located URI changes so we can get the benefit of depesz's work on that |
| 13:19 |
eeevil |
(I consider it a bug, not a feature, fwiw, so IMO it doesn't have to happen today |
| 13:19 |
eeevil |
dbwells: if you disagree, that's fine and I'll stand down ;) |
| 13:19 |
berick |
not sure of the context, but agreed p_pref_lib serves no purpose there |
| 13:20 |
eeevil |
it's ignored in practice, but it's the first thing the function does and it frightens me when the first line has a logic error |
| 13:24 |
dbwells |
eeevil: I don't mind generally calling performance improvements "bugs" for RC purposes. Post the .0 release, I'd tend to be more careful, I think. |
| 13:24 |
Dyrcona |
p_pref_lib.depth would make some sense, I guess. |
| 13:24 |
Dyrcona |
If that's even reachable from there. |
| 13:25 |
dbwells |
eeevil: Any decision can be swayed by the right combination of factors ;) |
| 13:28 |
eeevil |
;) |
| 13:30 |
|
jihpringle joined #evergreen |
| 13:32 |
csharp |
so, I'm trying my hand a writing a script to handle batch voiding for a specific OU or set of OUs for a specific date or set of dates... |
| 13:33 |
csharp |
I've learned that I can do $editor->search_actor_org_unit() and get full rows, but I'm looking for a similar way to get just the ids... |
| 13:33 |
csharp |
I'm sure it's simple for those who already know, so I thought I'd ask |
| 13:34 |
csharp |
I've been searching for a guide for cstore queries similar to the JSON guide, but I don't see one |
| 13:36 |
berick |
csharp: $editor->search_actor_org_unit({query..}, {idlist => 1}) |
| 13:36 |
berick |
also: $editor->search_actor_org_unit([{query}, {flesh}], {idlist => 1}) |
| 13:36 |
csharp |
berick++ #excellent |
| 13:37 |
csharp |
yay - that works |
| 13:38 |
dbwells |
csharp: Also, for more general cases, you can use the same JSON query stuff using $editor->json_query() |
| 13:39 |
dbwells |
csharp: You just need to Perl-ize the notation a bit (which mostly amounts to turning colons into =>) |
| 13:40 |
dbwells |
Maybe that's not what you meant. |
| 13:44 |
Dyrcona |
You can turn JSON into Perl using the JSON module and it's decode_json function. |
| 13:45 |
Dyrcona |
So, any JSON query can easily be used with CStoreEditor. |
| 13:45 |
csharp |
dbwells: thanks for that further info |
| 13:45 |
csharp |
Dyrcona: I'm using your myprefs.d method for authentication, btw ;-) |
| 13:45 |
Dyrcona |
:) |
| 13:45 |
csharp |
hooray for free software! |
| 13:46 |
csharp |
graced: you around? I have us down for lunch tomorrow - are you still game? |
| 13:46 |
csharp |
doh - meant that to be PM'd |
| 13:47 |
davidcandlestick |
hi everyone. I have a question about licensing. We would like to offer evergreen to a new research center, as part of a tender offer. Can we charge for evergeeen? Thank you. |
| 13:47 |
dbs |
davidcandlestick: absolutely |
| 13:49 |
Dyrcona |
Evergreen itself is covered by the GPL. Bits that it uses may have different licenses. |
| 13:49 |
dbs |
eeevil: what's the context for that chunk of code? |
| 13:50 |
eeevil |
dbs: commit 3bf9f947a57e3621724c9a22441a47e9b9cf682d in branch http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dyrcona/lp1234845_ranked_volumes |
| 13:50 |
dbs |
eeevil: ah, I see. that's why I couldn't find it in master :) |
| 13:50 |
eeevil |
indeed :) |
| 13:59 |
Dyrcona |
eeevil: I think you'd have to ask depesz about that code. I only made the branch from what he shared. |
| 13:59 |
Dyrcona |
only thing I added was the drop function bit. |
| 14:01 |
* jeff |
attempts to catch up on bug 1198465 |
| 14:01 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 10, heat: 38) [Wishlist,Confirmed] https://launchpad.net/bugs/1198465 |
| 14:06 |
Dyrcona |
dwells: I thought that I got all of those, but I'll have another look at bill2.js this evening. |
| 14:24 |
berick |
dbwells: (or anyone) new bugs (not features), can those be targeted at beta-1 or is everyhing going into rc1 now regardless of bug-ishness? |
| 14:25 |
dbwells |
berick: If it is high or critical, please target at beta1, otherwise I'd say wait for rc1. Does that work for you? |
| 14:25 |
berick |
dbwells: indeed it does |
| 14:25 |
berick |
thanks |
| 14:28 |
jeff |
:q |
| 14:29 |
jeff |
grr. |
| 14:29 |
Dyrcona |
Heh. One advantage of being an Emacs user: my wrong window commands almost never show up in IRC. |
| 14:31 |
jeff |
yup. :-) |
| 14:31 |
|
sseng joined #evergreen |
| 14:33 |
|
jammin joined #evergreen |
| 14:47 |
bshum |
berick: LOL, bug 1281750 sounds entertaining. |
| 14:47 |
pinesol_green |
Launchpad bug 1281750 in Evergreen "Fetching user group info on deleted users creates unnecessary load" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1281750 - Assigned to Bill Erickson (erickson-esilibrary) |
| 14:47 |
berick |
bshum: hope you like my stream of consciousness ;) |
| 14:47 |
bshum |
By "entertaining" I really mean, "OH MY GOD, MAKE IT STOP, PLEASE!!!!" |
| 14:48 |
bshum |
:) |
| 14:48 |
bshum |
berick++ |
| 14:55 |
dbwells |
I am planning to extend the beta period till Friday due to heavy, ongoing activity on a couple of the blockers. Would anyone here fervently object to that? |
| 14:55 |
bshum |
+1 to extension |
| 14:56 |
Dyrcona |
No, that's fine with me. |
| 14:58 |
berick |
+1 |
| 15:01 |
eeevil |
+1 # march is still a ways of! ;) |
| 15:10 |
jeff |
+1 to extension |
| 15:21 |
berick |
crazy. just hit 60 degrees and there's still a large patch of (thin) snow outside the window. |
| 15:23 |
jeff |
i think i just confused the conditional negative balance branch by violating its assumptions. |
| 15:24 |
jeff |
checked something out, set its due date back a ways, ran fine generator, made some payments, did a backdated checkin. |
| 15:24 |
jeff |
i suppose that's an unfair test, and i think our local branches have suffered similar fates before. |
| 15:25 |
jeff |
but this brings up a good question: what is a recommended method of testing overdues -- manually create the checkout many days ago? |
| 15:25 |
* jeff |
goes to see what make livecheck does |
| 15:25 |
berick |
jeff: the seed data has some overdues in it |
| 15:25 |
jeff |
my usual trick is the above, check out and then set a due date in the past (which means it becomes due before checkout), then run fine generator. it works for many things until it doesn't. :-) |
| 15:27 |
jeff |
okay, livecheck rewrites history with open-ils.cstore.direct.action.circulation.update |
| 15:27 |
jeff |
still "cheating" (what tests aren't?) but results are cleaner. |
| 15:46 |
|
stevenyvr joined #evergreen |
| 15:59 |
|
Dyrcona joined #evergreen |
| 16:11 |
|
dMiller_ joined #evergreen |
| 16:14 |
eeevil |
dbwells / berick: found it, I believe. it's the composite attr compiler |
| 16:15 |
eeevil |
yep |
| 16:15 |
berick |
eeevil++ |
| 16:15 |
eeevil |
pushing a 2-line fix in a moment |
| 16:34 |
eeevil |
and, implementing a speedup ... to address general indexing concerns |
| 16:35 |
|
dMiller___ joined #evergreen |
| 16:40 |
Bmagic |
Anyone have a tool to extract the marc records with holdings attached via multithread to cut the time down? The tool that we have takes almost 7 full days to finish extracting 1.7GB of data |
| 16:45 |
|
Dyrcona joined #evergreen |
| 16:46 |
eeevil |
dbwells / berick: I killed the memory problem, AND now reingest takes <10s for the concerto data on the same server (full reingest). just the icon_format takes .5s :) |
| 16:47 |
|
dcook joined #evergreen |
| 16:48 |
davidcandlestick |
hi everyone, another question. What is the most established, most used paid ILS software out there? If we propose Koha to our client, what paid solution will they compare us to? Our customer has a single location.s to? |
| 16:50 |
Dyrcona |
davidcandlestick: That is a question that I'm not sure anyone in here really knows the answer to. |
| 16:52 |
senator |
davidcandlestick: if you're going to sell library software to somebody, maybe hire somebody who actually knows library software? |
| 16:52 |
jeff |
blarg. java. |
| 16:53 |
jcamins |
davidcandlestick: it depends on the specific situation of the library. You might look at Marshall Breeding's surveys, bearing in mind that they are not going to tell you the important things, which are "which ILS(es) did the most senior library staff learn on? What systems have they seen and liked? What are other libraries in the area using that might impact their decision?"... and several dozen others. |
| 16:54 |
jcamins |
davidcandlestick: also, there is often no clear market leader even in a well-defined, at-equilibrium market segment. |
| 16:59 |
Dyrcona |
Yeah, you could say that the ILS market is actually a functioning, competitive market. |
| 17:00 |
eeevil |
dbwells / berick: please see the top of http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/lp1053397-tpac-metarecords-r5 |
| 17:01 |
* berick |
takes a look |
| 17:02 |
eeevil |
berick: to see it in action, your test server has it in place already |
| 17:02 |
jcamins |
Dyrcona: let's not go overboard. Have you seen some of the ILSes out there? :P |
| 17:02 |
eeevil |
evergreen=# select metabib.reingest_record_attributes(id,'{icon_format}'::TEXT[],marc,false) from biblio.record_entry where id > 0 and not deleted; |
| 17:02 |
eeevil |
Time: 477.551 ms |
| 17:03 |
berick |
eeevil: thanks. i'll install on a new DB though, to test the baseline as well |
| 17:03 |
eeevil |
berick: fair :) |
| 17:03 |
Dyrcona |
jcamins: Yes, they all suck, some just suck less. :) |
| 17:04 |
pastebot |
"berick" at 64.57.241.14 pasted "for eeevil :)" (17 lines) at http://paste.evergreen-ils.org/22 |
| 17:05 |
eeevil |
well that's fun |
| 17:05 |
eeevil |
I wonder why it works on the test db... |
| 17:09 |
eeevil |
berick: pushing the fix... just RETURN NULL; |
| 17:09 |
berick |
ah |
| 17:09 |
eeevil |
pushed |
| 17:10 |
eeevil |
well |
| 17:10 |
eeevil |
ing |
| 17:10 |
eeevil |
pushd |
| 17:10 |
berick |
thanks, running again |
| 17:11 |
|
mmorgan left #evergreen |
| 17:18 |
berick |
works well. memory looks good. full re-ingest still takes longer (but i'd be shocked if it didn't). |
| 17:18 |
berick |
though speed is considerably improved |
| 17:19 |
berick |
master = 17 seconds; old MR branch = 50 seconds; new MR branch = 30 seconds. |
| 17:19 |
berick |
on my test vm |
| 17:19 |
eeevil |
ah, I should have said that full attr reingest (all we need for the upgrade to this) only takes 10s |
| 17:19 |
eeevil |
not full marc dance |
| 17:20 |
berick |
that's what I thought you meant |
| 17:20 |
berick |
i'm just covering the bases |
| 17:21 |
berick |
eeevil++ |
| 17:21 |
eeevil |
well, I broke it, I should fix it ;) |
| 17:21 |
* berick |
noticed the initial seed data insert happend noticeably faster as well |
| 17:22 |
eeevil |
yeah, after the first record is processed, the CRA defs are cached |
| 17:22 |
eeevil |
I would expect the same proportional speedup for insert and reingest |
| 18:13 |
fparks_ |
eeevil: are you still around? |
| 18:46 |
|
davidcandlestick joined #evergreen |
| 18:58 |
|
mrpeters left #evergreen |
| 19:11 |
bshum |
Bmagic: Assuming you mean tools for extracting MARC records with holdings from Evergreen, which are you currently employing? I can think of at least two known ways right now. 1) use of the existing marc_export, 2) vandelay import/export via the staff client. |
| 19:11 |
bshum |
Bmagic: For both of those, they can be super slow. |
| 19:12 |
bshum |
We make primarily use of marc_export in our system and running each bib out in sequence one at a time (with holdings) can take us upwards of 26 hours. |
| 19:13 |
bshum |
What I've done in the past was to setup concurrent runs of marc_export, each with its own list of bib IDs. |
| 19:13 |
bshum |
So I would say IDs 1 through the first 100k would run on this, then another group, etc. |
| 19:13 |
bshum |
And set those to run in parallel |
| 19:14 |
bshum |
That all said... there is work underway to make things faster overall. |
| 19:14 |
bshum |
One of the branches I've assigned to myself and plan to push shortly for 2.6 beta is https://bugs.launchpad.net/evergreen/+bug/1223903 |
| 19:14 |
pinesol_green |
Launchpad bug 1223903 in Evergreen "marc_export with --items is too damned slow and other things" (affected: 2, heat: 10) [Wishlist,Confirmed] - Assigned to Ben Shum (bshum) |
| 19:15 |
bshum |
From my testing so far, the new marc_export that Dyrcona creates in his working branch is MUCH faster at its job. |
| 19:15 |
bshum |
And you can still run it in parallel groups. |
| 19:16 |
bshum |
I think a run of 100k records from our system normally takes about 1-2 hours and with his new script, we did the same batch less than half an hour. |
| 19:21 |
|
RBecker joined #evergreen |
| 19:21 |
|
artunit joined #evergreen |
| 19:36 |
|
Dyrcona joined #evergreen |
| 19:37 |
Dyrcona |
If I'm reading things correctly, a virtual field in a Fieldmapper class can be used to for a sort of reverse foreign key relationship lookup. |
| 19:38 |
|
RBecker joined #evergreen |
| 19:38 |
Dyrcona |
And, looks like it would usually have to be fleshed to be filled in. |
| 19:45 |
|
davidcandlestick joined #evergreen |
| 19:57 |
Dyrcona |
Hmm... I wonder about a might_have vs. has_many when there could be 0 to infinity. |
| 20:03 |
Dyrcona |
And you discover something that, if you had done it this way from the beginning, would have made for a lot less work. |
| 20:26 |
Dyrcona |
Well, of course. Nothing ever works the way that I think it should. |
| 20:26 |
* Dyrcona |
shrugs and gives up on that tack. |
| 20:33 |
eeevil |
Dyrcona: might_have is for the referenced side of an fkey, as you suggest, where the referent will have only one referrer. like, say, bre.rec_descriptor (or however thats spelled) |
| 20:34 |
eeevil |
it's basically a has_many that takes only the first referring row |
| 20:34 |
Dyrcona |
eeevil: Thanks for confirming. |
| 20:36 |
Dyrcona |
I was trying to get a virtual field to link to another object whose table has a fk relationship with the table for the first class, but the first class's table doesn't reference the second class's table. |
| 20:36 |
Dyrcona |
Doesn't seem to work like that. |
| 20:37 |
eeevil |
new tables, or lacking idl classes? |
| 20:37 |
Dyrcona |
existing idl classes actually. |
| 20:38 |
Dyrcona |
money.billing and money.void_payment: the latter refers to the former but not the other way around. |
| 20:38 |
Dyrcona |
I was trying to add a virtual field to the mb class to reference mvp (money.void_payment). |
| 20:39 |
Dyrcona |
I got the virtual field to exist, but didn't get any data out of it. |
| 20:40 |
eeevil |
so you want a mb.voided_payments virt field |
| 20:40 |
Dyrcona |
yes. |
| 20:42 |
Dyrcona |
<field reporter:label="Void Payment" name="void_payment" oils_persist:virtual="true" reporter:datatype="link"/> |
| 20:43 |
Dyrcona |
<link field="void_payment" reltype="might_have" key="billing" map="id" class="mvp"/> |
| 20:43 |
Dyrcona |
Was what I tried first, then I tried swapping key and map. |
| 20:44 |
eeevil |
map isn't what you want |
| 20:44 |
eeevil |
that does something else |
| 20:44 |
Dyrcona |
ok |
| 20:44 |
eeevil |
it jumps through the remote table |
| 20:45 |
eeevil |
im on my phone... lemme get out a laptop |
| 20:45 |
Dyrcona |
thanks. |
| 20:47 |
|
davidcandlestick joined #evergreen |
| 20:48 |
eeevil |
I don't see a class called mvp in head |
| 20:48 |
eeevil |
I guess that's in your branch? |
| 20:48 |
Dyrcona |
Yes, it is. |
| 20:48 |
|
jboyer-laptaupe joined #evergreen |
| 20:48 |
eeevil |
in any case, what's the field on mvp that points at mb.id? billing? |
| 20:49 |
Dyrcona |
Yes. |
| 20:49 |
eeevil |
if so, just say map="" and you're done |
| 20:49 |
Dyrcona |
mvp.billing -> mb.id |
| 20:49 |
Dyrcona |
cool. I was just going to try that after what you said earlier. |
| 20:50 |
eeevil |
the way has_many and might_have work is that they assume the foreign table's field named in @key points at the local tables pkey |
| 20:50 |
eeevil |
as defined by @oils_persist:primary on the <fields> element |
| 20:51 |
eeevil |
(btw, IIRC, map only works on has_a reltypes currently. the semantics of many-to-many-to-one seemed more trouble than they were worth, if memory serves) |
| 20:53 |
Dyrcona |
ok. |
| 20:53 |
eeevil |
huh ... seems I lied. it's actually only in use on has_many and might_have columns |
| 20:54 |
Dyrcona |
I'm not getting anything on a bill that has a corresponding void_payment, though. |
| 20:54 |
Dyrcona |
I wonder if I have to do something in Storage, too. |
| 20:55 |
eeevil |
you're using flesh=>1, flesh_fields=>{mb=>['void_payment']}}? |
| 20:55 |
eeevil |
(I'm assuming cstore/pcrud) |
| 20:55 |
eeevil |
if you're trying to use the C::DBI interface inside Storage, you'll have to do more than set up the IDL, yes |
| 20:56 |
eeevil |
using storage for blind retrieval is deprecated ... |
| 20:57 |
eeevil |
even storage calls cstore for some things ;) |
| 20:59 |
Dyrcona |
ok. |
| 20:59 |
eeevil |
if you want to set up the C::DBI relationships, you'll have to touch Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/CDBI/money.pm and the bottom half of Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/CDBI.pm |
| 20:59 |
Dyrcona |
I was just checking fm_IDL.xml for similar types of links, and it looks like cbrebi -> cbrebin works like this. |
| 20:59 |
Dyrcona |
I wasn't doing the flesh. |
| 20:59 |
eeevil |
note, you'll just use has_a in the latter ... C::DBI doesn't care if it's null |
| 21:01 |
eeevil |
cbrebi->cbrebin does work like that, but you have to flesh to get the notes |
| 21:03 |
Dyrcona |
eeevil++ |
| 21:03 |
Dyrcona |
Thanks! I have it working, now. |
| 21:03 |
eeevil |
sweet. now if only I was a fan of voiding by payment ;) |
| 21:03 |
* eeevil |
ducks |
| 21:03 |
Dyrcona |
heh. |
| 21:04 |
eeevil |
ftr, dbwells and I share the same opinion on "the thing called void" ... <whisper>it never happened</> |
| 21:04 |
eeevil |
but, it may just be a terminology issue that's keeping from properly conceptualizing what your doing |
| 21:05 |
eeevil |
much as dbwells suggested in his comment, as well |
| 21:06 |
* eeevil |
runs away for the evening |
| 21:07 |
eeevil |
Dyrcona: glad that's working, and glad there's another soul that now understands some of the deeper bits of the IDL and cstore et al |
| 21:08 |
Dyrcona |
Yeah, I think I finally get most of how it works. |
| 21:10 |
Dyrcona |
As far as making the void payment, I thought it would make things simpler to just treat a void like another type of payment. |
| 21:10 |
Dyrcona |
But, anyway..... Good night! |
| 22:14 |
|
zxiiro_ joined #evergreen |
| 22:40 |
|
zerick joined #evergreen |
| 22:46 |
|
davidcandlestick joined #evergreen |
