| Time |
Nick |
Message |
| 07:36 |
|
jboyer-isl joined #evergreen |
| 07:44 |
|
jboyer-isl joined #evergreen |
| 07:47 |
|
jboyer_isl joined #evergreen |
| 07:48 |
|
jboyer-isl joined #evergreen |
| 08:09 |
|
julialima_ joined #evergreen |
| 08:20 |
|
rjackson_isl joined #evergreen |
| 08:21 |
|
graced joined #evergreen |
| 08:25 |
|
ericar joined #evergreen |
| 08:31 |
|
collum joined #evergreen |
| 08:34 |
|
mrpeters joined #evergreen |
| 08:43 |
|
jboyer-isl joined #evergreen |
| 08:46 |
|
RoganH joined #evergreen |
| 08:52 |
|
jwoodard joined #evergreen |
| 09:02 |
|
Arlene joined #evergreen |
| 09:04 |
|
abowling joined #evergreen |
| 09:17 |
|
maryj joined #evergreen |
| 09:29 |
|
RoganH joined #evergreen |
| 09:35 |
|
mdriscoll joined #evergreen |
| 09:39 |
|
mmorgan1 left #evergreen |
| 09:41 |
|
mmorgan joined #evergreen |
| 10:01 |
|
yboston joined #evergreen |
| 10:06 |
|
Dyrcona joined #evergreen |
| 10:06 |
|
Arlene joined #evergreen |
| 10:32 |
|
mrpeters joined #evergreen |
| 10:35 |
|
buzzy joined #evergreen |
| 10:35 |
|
pmurray joined #evergreen |
| 10:36 |
|
RoganH joined #evergreen |
| 10:38 |
rjackson_isl |
appear to be running into bug 1091885 where a bib record is undeleted and there is no entry in metabib.record_attr |
| 10:38 |
pinesol_green |
Launchpad bug 1091885 in Evergreen "Reingest bib needs to deal with missing metabib.record_attr entries" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1091885 |
| 10:38 |
bshum |
Yeah that'll happen |
| 10:38 |
rjackson_isl |
before upgrading to 2.7.2 the entry was a table |
| 10:39 |
rjackson_isl |
but now it is a view and table related is metabib.record_attr_vector_list I think |
| 10:39 |
rjackson_isl |
how do we repopulate so undeleted bib can be searched again? |
| 10:40 |
bshum |
rjackson_isl: Presumably the same basic idea ought to work I think. |
| 10:41 |
bshum |
Insert an entry with anything in it. Then reingest the bib record |
| 10:41 |
bshum |
To create the actual values |
| 10:41 |
rjackson_isl |
the table has a vlist column type integer[] not null?? |
| 10:42 |
rjackson_isl |
just dump anything in that column that satisifies the type? |
| 10:42 |
bshum |
rjackson_isl: Pretty much what I would try first, yeah. |
| 10:42 |
rjackson_isl |
bshum++ will do |
| 10:43 |
bshum |
If that does work, then I would update your findings with the new MVF/CRA framework from 2.6+ in mind for that bug. |
| 10:44 |
bshum |
The bug was reported much earlier, before changes to metabib.record_attr happened during the 2.6 era. |
| 10:44 |
bshum |
Undeleted bib records are just plain messy :) |
| 10:45 |
|
maryj joined #evergreen |
| 10:47 |
|
BigRig joined #evergreen |
| 11:24 |
dbs |
s/Undeleted // |
| 11:25 |
bshum |
:D |
| 11:32 |
|
nhilton joined #evergreen |
| 11:37 |
|
buzzy joined #evergreen |
| 11:42 |
bshum |
rjackson_isl++ # thanks for sharing your findings. |
| 11:42 |
bshum |
Glad it worked out in the end, but I'm still perturbed by that bug in general. |
| 12:04 |
|
bmills joined #evergreen |
| 12:08 |
RoganH |
Here's a quick question, what, historically, was the intended difference between circulating library and owning library in the asset.copy table? |
| 12:09 |
bshum |
RoganH: I think owning library is actually on the asset.call_number table? |
| 12:10 |
RoganH |
Oh, you're right it is. |
| 12:10 |
* bshum |
has guesses on the rest of that, but will let some original devs talk about original intents |
| 12:10 |
RoganH |
In my head (I was in the staff client) they were mashed together. |
| 12:10 |
berick |
library A owns the copy, but it lives temporarily at library B (circ lib) |
| 12:10 |
bshum |
My assumption was that it allowed an item to be owned by one library, but then circulated elsewhere. And when returned it would go to whichever circ lib it lived at. |
| 12:11 |
RoganH |
berick: that's what I was assuming but it's good to know |
| 12:22 |
dbwells |
re: circ vs owning lib, I understand how it works in practice, but I don't think I've ever really understood the design. Is it just a matter of convenience that owning_lib is on the call_number? That there tend to be fewer owners than circ-ers, so this was a handy way to group them for permissions, etc.? |
| 12:25 |
dbs |
I think the idea was also that systems could "own" call numbers, to prevent dupes of non-deleted call numbers, and just distribute copies amongst their branches. |
| 12:27 |
mmorgan |
Anybody have experience using a different owning vs. circ library in practice? |
| 12:28 |
berick |
what dbs said... a call number was basically defined from the beginning as a label + a location (org unit). |
| 12:31 |
bshum |
mmorgan: In most cases, it's the same for our libs. The only time it really differs is during summer reading months where school libs sometimes transfer copies over to the public libs in their towns for broader use. |
| 12:32 |
bshum |
That'd be a case where the school lib was owning lib, but the copy was changed to have the local town lib as the circ lib. |
| 12:32 |
bshum |
Other than that, I don't think we have too many other use cases where those differ. |
| 12:32 |
dbwells |
I guess the odd thing for me with that definition is that the label is owned by a location, but depending on the circ lib, isn't necessarily /at/ that location. I find that confusing, but maybe it's just me. |
| 12:32 |
bshum |
Even with our branch libs, they all tend to keep things separated. |
| 12:34 |
RoganH |
We've kept things separated as well but we're starting to rethink things. As we've looked more at floating type behaviors there are things that are presenting difficulties and some bad practices that have gone unnoticed for a long time biting us in the rear. |
| 12:34 |
RoganH |
I've found I've had to step back and think about how to make this a bit cleaner and some perspective about intent is useful. |
| 12:39 |
|
ericar_ joined #evergreen |
| 12:43 |
dbs |
dbwells: an entry in the OU hierarchy isn't necessarily a location, but instead can just be an organization |
| 12:44 |
dbs |
e.g. we have Laurentian University as the parent of a bunch of on-campus libraries, and e-resources are owned by it |
| 12:45 |
|
buzzy joined #evergreen |
| 12:55 |
dbwells |
dbs: That's a good point. Though maybe it should be owning_org, then ;) |
| 13:00 |
dbs |
also a good point! |
| 13:03 |
|
krvmga joined #evergreen |
| 13:04 |
krvmga |
in our catalog ( http://catalog.cwmars.org ) looking up History of the world in 1,000 objects http://bark.cwmars.org/eg/opac/results?query=history+1%2C000+objects&qtype=keyword&fg%3Aformat_filters=&locg=1 |
| 13:05 |
krvmga |
only gets the correct return is 1,000 has a comma in it (or some other non-alpha non-numeric character) |
| 13:05 |
dbwells |
mmorgan: We tried having them different with a collection which was changing ownership (aka management), but not location. One issue we ran into is that Holdings Maintenance is scoped by Owning Library, and this caused great confusion for staff who were used to thinking of it as a location-based tree. |
| 13:05 |
krvmga |
so 1#000, 1%000, 1&000, 1*000, 1 000 and so on all work |
| 13:06 |
krvmga |
i didn't find a bug on launchpad about punctuation this way |
| 13:07 |
krvmga |
could this be some configuration that we've done in a bizarre way? |
| 13:07 |
krvmga |
or is this normal behavior of the system right now? |
| 13:07 |
dbs |
that's normal behaviour |
| 13:07 |
dbs |
NACO normalization to be exact |
| 13:07 |
krvmga |
dbs: thanks for that. |
| 13:08 |
krvmga |
it's a little crazy-making for some of my member staff. |
| 13:10 |
dbs |
the normalization algorithm clearly focuses on text rather than numbers |
| 13:11 |
* bshum |
wants to put a reminder to folks that it's never too early to put ideas out for programs for Evergreen 2015: http://wiki.evergreen-ils.org/doku.php?id=conference:2015:proposals |
| 13:11 |
bshum |
:D |
| 13:12 |
* dbs |
wonders about normalizing 1.234567 x 10^6 and 1,234,567 to "1234567" |
| 13:13 |
dbs |
and heck, 1.234567E+06 |
| 13:13 |
dbs |
and "1 234 567" for metric countries |
| 13:13 |
dbs |
normalization is not easy. |
| 13:13 |
* jeff |
wonders if there was a survey after the last conference with the "what would you like to see covered in 2015 in terms of programs" |
| 13:14 |
kmlussier |
jeff: No |
| 13:14 |
jeff |
kmlussier++ thanks! |
| 13:18 |
dbs |
"Please don't have Dan bore us again with another schema.org thing." probably top of the list if that had happened |
| 13:18 |
|
collum joined #evergreen |
| 13:19 |
bshum |
dbs: Oh submit away! I'll make sure you get the room with the beautiful view. That way people can just stare outside if it's that boring ;) |
| 13:20 |
kmlussier |
dbs: Please submit something on schema.org. I missed your presentation last year because I was presenting last time. |
| 13:20 |
bshum |
dbs' presentations are always awesome. |
| 13:20 |
dbs |
oh please |
| 13:20 |
bshum |
All kidding aside :) |
| 13:20 |
jeff |
dbs++ |
| 13:20 |
bshum |
dbs++ |
| 13:21 |
kmlussier |
Not to programming committee, please don't schedule me against dbs this year. I barely had an audience. |
| 13:21 |
kmlussier |
s/Not/Note |
| 13:21 |
dbs |
*I* wanted to be at your presentation, kmlussier |
| 13:21 |
|
buzzy joined #evergreen |
| 13:21 |
RoganH |
I wanted to be at both. |
| 13:22 |
kmlussier |
buzzy must have heard that we were talking about conference stuff. :) |
| 13:22 |
* dbs |
remembers suddenly and horribly that he's supposed to be sitting with the technicians working through acquisitions training |
| 13:22 |
bshum |
dbs: Have you considered a presentation on acquisitions? Given your newfound experiences :D |
| 13:23 |
dbs |
bshum+- |
| 13:23 |
bshum |
Hehe |
| 13:24 |
ningalls |
conference is in May this year? not good if it lands on any days involving the Indy 500 |
| 13:24 |
* kmlussier |
would gladly heckle from the audience for that presentation. :) |
| 13:24 |
kmlussier |
ningalls: When is the Indy 500? |
| 13:24 |
ningalls |
May 24th |
| 13:25 |
bshum |
ningalls: I think it's before. Evergreen 2015 is May 13-16 |
| 13:25 |
ningalls |
those dates are safe |
| 13:25 |
ningalls |
whoo |
| 13:25 |
kmlussier |
But it is the same week as the National GeoBee competition. |
| 13:35 |
|
dcook joined #evergreen |
| 13:53 |
kmlussier |
This looks fun - https://play.google.com/store/apps/details?id=com.thehoick.evergreenflixq |
| 13:55 |
tsbere |
Interesting on the surface, if I used Netflix....and if not for little things like "This app is incompatible with all of your devices." |
| 13:56 |
|
jihpringle joined #evergreen |
| 14:06 |
jeff |
Alas, I'm guessing the fact that Netflix is killing or has killed their API kills that app pretty dead. |
| 14:06 |
* jeff |
bookmarks to look into |
| 14:09 |
mrpeters |
wow thats pretty cool |
| 14:09 |
mrpeters |
has to be first Evergreen app officially in a store, yeah? |
| 14:21 |
jeff |
depends on what your definition is, i suppose. |
| 14:22 |
mrpeters |
true, still a neat idea and glad someone had interest to develop it |
| 14:22 |
jeff |
agreed. |
| 14:24 |
kmlussier |
jeff: It looks like it only uses the DVD queue RSS feed from Netflix. As long as the RSS feed still exists, I expect the app would continue to work. |
| 14:33 |
jeff |
relevant: http://codepen.io/asommer70/blog/evergreen-flixq-developing-a-2nd-android-app |
| 14:33 |
berick |
:w |
| 14:33 |
dbs |
:q! |
| 14:33 |
berick |
uh, yeah, that's how I save my IRC history |
| 14:33 |
berick |
that's the ticket |
| 14:34 |
mmorgan |
:) |
| 14:46 |
dbwells |
berick: Let any vim users among us who haven't typed ":w" into IRC throw the first stone |
| 14:47 |
berick |
heh |
| 14:49 |
jcamins |
kk^[kkI |
| 15:00 |
Dyrcona |
Emacs has an IRC mode. Just sayin'. |
| 15:01 |
jcamins |
Dyrcona: yeah, but it requires you to press Control-meta-meta-butterfly-IRC |
| 15:02 |
Dyrcona |
pfft. |
| 15:07 |
Dyrcona |
But you can remap that to just 'i' if you want. ;) |
| 15:09 |
RoganH |
I'm waiting for the sci fi novel that speculates that all of reality is just a series of really complicated emac macros that simulates the universe. |
| 15:10 |
Dyrcona |
RoganH: It hasn't written itself, yet, but give it time. |
| 15:10 |
mtate |
RoganH++ |
| 15:11 |
jcamins |
RoganH: there's a macro for that: up down up down up down left right left right a b a b a |
| 15:11 |
RoganH |
I thought that was just for cheating at Contra. |
| 15:12 |
Dyrcona |
Funny how everyone calls them macros, when more often than you not, you end up writing full-blown programs in elisp. |
| 15:12 |
Dyrcona |
Back to what I was talking about at around 10:00 to 10:30 PM EST yesterday..... |
| 15:12 |
Dyrcona |
I checked that open-ils.actor.patron.update works when called normally on my development vm, so nothing I loaded broke it. |
| 15:13 |
Dyrcona |
I also get the same error against my production machine as I do on development, and the line in question is looking up data in the user that it supposedly pulled from the database. |
| 15:14 |
Dyrcona |
I used the same IDL to create my actor user object as we use on the respective servers, so I don't think fields are out of sync. |
| 15:14 |
Dyrcona |
I *may* actually dig into this with the debugger, but probably not on MVLC's time. |
| 15:14 |
Dyrcona |
I just wanted to make sure nothing in master or a dev branch I loaded had broken open-ils.actor. |
| 15:15 |
Dyrcona |
Meta-x god-mode |
| 15:16 |
* Dyrcona |
should actually implement a god-mode. |
| 15:26 |
|
Dyrcona1 joined #evergreen |
| 15:26 |
|
akilsdonk joined #evergreen |
| 15:27 |
bshum |
You know |
| 15:28 |
bshum |
I'm not 100% sure, but I don't think reingesting was absolutely required between 2.6 and 2.7 |
| 15:28 |
kmlussier |
bshum: That's a good thing, right? |
| 15:28 |
bshum |
Reading all the stuff in the upgrade scripts, I don't see anything that explicitly requires it. |
| 15:28 |
* Dyrcona |
grumbles about lousy office wifi. |
| 15:28 |
bshum |
kmlussier: Yeah, it is and it's also kind of un-nerving. |
| 15:29 |
dbwells |
We upgraded from 2.6 to 2.7 last week, and didn't do a reingest. So far, so good. |
| 15:30 |
Dyrcona |
2.7.1 requires a mra ingest, doesn't it? |
| 15:31 |
* bshum |
double checks, but didn't see anything |
| 15:32 |
Dyrcona |
Thought it was suggested after one of the database performance improvement upgrades. |
| 15:32 |
bshum |
Nope it was just view changes |
| 15:34 |
dbwells |
The only thing I can think of is bug #1322285, but I'm honestly not sure how that ended up in the upgrade stream. |
| 15:34 |
pinesol_green |
Launchpad bug 1322285 in Evergreen 2.6 "MVF ingest uses default values inappropriately " (affected: 1, heat: 8) [Undecided,Fix released] https://launchpad.net/bugs/1322285 |
| 15:35 |
dbwells |
My understanding is that coming from 2.6.3, you will now be alright. |
| 15:35 |
dbwells |
But I didn't actually look into it. |
| 15:35 |
bshum |
dbwells: I think we put a note to run the 2.6.3 script if it was missed along the way (since it retroactively didn't break anything to run it after getting to 2.7 either) |
| 15:38 |
bshum |
That particular script and bug entries did not include an instruction to reingest |
| 15:38 |
dbwells |
You're right, but I think it probably should have, if I understand it. |
| 15:38 |
bshum |
If we should reingest, then we could add an instruction to do that somewhere... sigh. |
| 15:40 |
dbwells |
My feelings exactly. If a reingest is needed, that upgrade script should at least spit out the "hey, you need to reingest now, here's a way" message. |
| 15:40 |
bshum |
Rigt. |
| 15:40 |
bshum |
*right |
| 15:41 |
bshum |
dbwells++ |
| 15:47 |
|
TaraC_ joined #evergreen |
| 15:50 |
bshum |
Calling 0904 |
| 15:50 |
bshum |
Putting https://bugs.launchpad.net/evergreen/+bug/1414112 through before we round up last things for cutting maintenance releases. |
| 15:50 |
pinesol_green |
Launchpad bug 1414112 in Evergreen 2.7 "Audience filter no longer searching blank spaces" (affected: 2, heat: 14) [Medium,Confirmed] |
| 15:53 |
dbwells |
eeevil (or anyone else): is there a shortcut way to deal with whatever reingesting is needed for bug #1322285? I know there's ways to do limited ingests, but honestly can't remember the details, and don't have time to understand if any apply here :) |
| 15:53 |
pinesol_green |
Launchpad bug 1322285 in Evergreen 2.6 "MVF ingest uses default values inappropriately " (affected: 1, heat: 8) [Undecided,Fix released] https://launchpad.net/bugs/1322285 |
| 15:58 |
dbwells |
maybe just a "select metabib.reingest_metabib_field_entries(id)..." pile a la the 2.5 upgrade script, but I'm really not sure how much faster that is. |
| 15:58 |
pinesol_green |
[evergreen|Galen Charlton] LP#1414112: avoid excluding record attribute values that contain only blanks - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2406fe2> |
| 15:58 |
pinesol_green |
[evergreen|Mike Rylander] LP#1414112: Seed data and avoid reingest - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b792cca> |
| 15:58 |
pinesol_green |
[evergreen|Chris Sharp] LP#1414112: Correct usage of WITH clause for UPDATE. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bad8109> |
| 15:58 |
pinesol_green |
[evergreen|Ben Shum] LP#1414112: Stamping upgrade script for spaces in record attr values - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9452d11> |
| 15:58 |
bshum |
I'm going to go ahead and include https://bugs.launchpad.net/evergreen/+bug/1415572 too for bug fixing. |
| 15:58 |
pinesol_green |
Launchpad bug 1415572 in Evergreen 2.7 "outdated version of authority.normalize_heading can be present in certain upgraded databases" (affected: 3, heat: 16) [High,New] |
| 15:58 |
bshum |
Calling 0905 |
| 15:58 |
goood |
dbwells: theoretically, yes. you could remove the default values from the int array that aren't actually in the record. |
| 15:59 |
Dyrcona |
@dunno get 8 |
| 15:59 |
pinesol_green |
Dyrcona: Dunno #8: "Message root @ server God....Universe going down for reboot...." (added by csharp at 02:12 PM, July 03, 2012) |
| 16:00 |
dbwells |
goood: I am thinking the "select metabib.reingest_metabib_field_entries(id)..." style reingest will also do what we need in this case? (though obviously more heavy-handed) |
| 16:01 |
* dbs |
is a big fan of pingest.pl |
| 16:01 |
dbs |
Dyrcona++ |
| 16:04 |
pinesol_green |
[evergreen|Galen Charlton] LP#1415572: ensure correct version of authority.normalize_heading() is in place - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=166912d> |
| 16:04 |
pinesol_green |
[evergreen|Ben Shum] LP#1415572: Stamping upgrade script for ensuring correct version of authority.normalize_heading - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3753e26> |
| 16:04 |
|
Dyrcona joined #evergreen |
| 16:05 |
dbwells |
dbs: In your experience, does it actually save time, or just make it easier? |
| 16:08 |
dbwells |
Either is still a good thing, of course. |
| 16:08 |
pinesol_green |
[evergreen|Dan Wells] LP#1078593 Assorted small Serial.pm fixes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bbf4fe9> |
| 16:08 |
pinesol_green |
[evergreen|Dan Wells] LP#1078593 Add method for regenerating serial summaries - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=65c072e> |
| 16:08 |
pinesol_green |
[evergreen|Dan Wells] LP#1078593 Regenerate summaries when deleting issuances - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f108b8d> |
| 16:08 |
bshum |
Calling 0906 for https://bugs.launchpad.net/evergreen/+bug/1413660 |
| 16:08 |
pinesol_green |
Launchpad bug 1413660 in Evergreen 2.7 "z3950_attr_name_is_valid should be STABLE, not IMMUTABLE" (affected: 1, heat: 6) [Undecided,New] |
| 16:14 |
pinesol_green |
[evergreen|Bill Erickson] LP#1413660 Mark 39.50 config function STABLE - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=456f88a> |
| 16:14 |
pinesol_green |
[evergreen|Ben Shum] LP#1413660: Stamping upgrade script to change z3950 function - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f5436da> |
| 16:16 |
bshum |
berick: Minor quibble but your submitted changeset for https://bugs.launchpad.net/evergreen/+bug/1240119 lacks signoff, etc. Can fix that up and get it ship-shape for pushing again. |
| 16:16 |
pinesol_green |
Launchpad bug 1240119 in Evergreen 2.6 "support user activity logging in safe authtoken generation" (affected: 2, heat: 10) [Medium,Triaged] |
| 16:18 |
bshum |
dbwells: I'm pausing a few moments to do some reading on the commits for https://bugs.launchpad.net/evergreen/+bug/1390138 |
| 16:18 |
pinesol_green |
Launchpad bug 1390138 in Evergreen "Documentation: 2.7 upgrade docs need to be updated" (affected: 1, heat: 6) [Medium,Confirmed] |
| 16:18 |
|
maryj joined #evergreen |
| 16:18 |
bshum |
They're mostly good, but there's some minor edits I already see to change. |
| 16:18 |
bshum |
After that, I think I'm mostly set to cut 2.7.3, barring further changes that get pushed. |
| 16:42 |
dbs |
dbwells: both saves time, and makes it easier |
| 16:43 |
dbwells |
dbs: cool, thanks. I'll have to try it soon. |
| 17:17 |
|
mmorgan left #evergreen |
| 17:26 |
|
abowling joined #evergreen |
| 17:32 |
|
nhilton_ joined #evergreen |
| 17:41 |
|
dbwells_ joined #evergreen |
| 18:53 |
|
Dyrcona joined #evergreen |
| 19:34 |
|
buzzy joined #evergreen |
| 22:15 |
|
sarabee joined #evergreen |
| 22:21 |
|
sarabee joined #evergreen |
| 22:22 |
|
eeevil joined #evergreen |
