| Time |
Nick |
Message |
| 00:18 |
|
gsams joined #evergreen |
| 00:35 |
|
jlitrell joined #evergreen |
| 06:00 |
|
_robbat2|irssi joined #evergreen |
| 06:01 |
|
jonadab_znc joined #evergreen |
| 06:01 |
|
_bott_ joined #evergreen |
| 06:02 |
|
TaraC joined #evergreen |
| 06:02 |
|
TaraC_ joined #evergreen |
| 07:03 |
|
mrpeters joined #evergreen |
| 07:19 |
|
jboyer_isl joined #evergreen |
| 07:58 |
|
jboyer-isl joined #evergreen |
| 08:02 |
|
Dyrcona joined #evergreen |
| 08:05 |
|
rjackson_isl joined #evergreen |
| 08:16 |
|
ericar joined #evergreen |
| 08:33 |
|
Shae joined #evergreen |
| 08:34 |
bshum |
kmlussier: I just noticed something. Negative balances has no corresponding docs/RELEASE_NOTES_NEXT/* entry. |
| 08:35 |
|
mmorgan joined #evergreen |
| 08:35 |
bshum |
We probably need to compose something to make note of all the new settings available for upgraders. |
| 08:41 |
Dyrcona |
And, those settings are likely to change given lp 1479110 |
| 08:41 |
pinesol_green |
Launchpad bug 1479110 in Evergreen "Negative balance settings used in combination with one another should interact differently" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479110 |
| 08:41 |
Dyrcona |
So, maybe we should delay the alpha? |
| 08:42 |
bshum |
Dyrcona: Up to you, fearless leader. |
| 08:42 |
bshum |
:) |
| 08:42 |
Dyrcona |
Not to mention lp 1479107 |
| 08:42 |
pinesol_green |
Launchpad bug 1479107 in Evergreen "Replace manual void option with an "adjust to zero" option" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479107 |
| 08:44 |
bshum |
But personally, I don't know if "alpha" release ever gets the real love it should. |
| 08:44 |
bshum |
berick skipped alpha milestone during 2.8 |
| 08:44 |
bshum |
And I wonder if maybe it was a good move after all. |
| 08:50 |
|
akilsdonk joined #evergreen |
| 08:56 |
kmlussier |
I wonder if we can salvage anything from http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=6c1b0461e078241e532750f53012229ad044d67d |
| 08:57 |
kmlussier |
It's the entry I wrote 1 1/2 years ago |
| 08:58 |
kmlussier |
I think it's still good with some minor adjustments made to the 2nd paragraph. |
| 08:59 |
kmlussier |
But it would be good to see how those other two bugs are resolved just to make sure the release notes are accurate. |
| 09:04 |
|
mrpeters joined #evergreen |
| 09:16 |
Dyrcona |
Maybe we'll skip the alpha or put it off another week to see what happens? |
| 09:17 |
|
maryj joined #evergreen |
| 09:17 |
kmlussier |
dbwells: Do you have a sense of how much time will be needed for bug 1479107? |
| 09:17 |
pinesol_green |
Launchpad bug 1479107 in Evergreen "Replace manual void option with an "adjust to zero" option" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479107 |
| 09:19 |
kmlussier |
For bug 1479110, I would be curious to know if others agree with our assessment of how the settings should interact with each other. |
| 09:19 |
pinesol_green |
Launchpad bug 1479110 in Evergreen "Negative balance settings used in combination with one another should interact differently" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479110 |
| 09:24 |
dbwells |
kmlussier: If we model it straight after the void interface code, it should be pretty simple. I don't think it is worth delaying the alpha for, though. I think the alpha is a litmus test to see if we're way off track, which means undone stuff is a given. |
| 09:25 |
dbwells |
kmlussier: I could add with a high degree of confidence that it should take less time than the original bug. |
| 09:25 |
* dbwells |
ducks |
| 09:33 |
jeff |
and... now you've jinxed it. |
| 09:35 |
|
yboston joined #evergreen |
| 09:58 |
kmlussier |
I'm inclined to agree with Dyrcona on the alpha delay if it's something that can be done in a reasonable amount of time, just because it would be nice to have it in as good shape as possible for the litmus test. |
| 09:59 |
kmlussier |
But, as bshum said, Dyrcona is our fearless leader. |
| 10:01 |
kmlussier |
Of course, part of me is also thinking of all the documentation I have to write and wanting to get started on it as soon as possible. |
| 10:02 |
Dyrcona |
Well, you could get started on the documentation. |
| 10:03 |
Dyrcona |
I find it is sometimes better to write the documentation first, and then write the code so it works according to the documentation. ;) |
| 10:03 |
kmlussier |
Actually, that was an idea raised at the Google doc sprint. Maybe I should start doing it for all of MassLNC's development projects. :) |
| 10:08 |
jeff |
There have been some related ideas rolling around in my head for a while... |
| 10:08 |
|
rjackson_isl joined #evergreen |
| 10:09 |
jeff |
roughly, unpolished: "documentation based on the UI AND the code is better than documentation based on only one or the other" and "you never fully understand a feature until you try to document it" or "the rough edges of your code are never fully apparent until you attempt to document it" |
| 10:10 |
jeff |
but... something along those lines. |
| 10:14 |
|
jwoodard joined #evergreen |
| 10:29 |
mrpeters |
I'm attempting to change the biblio.record_entry.source on about 6,000 items, it's going on 12 hours now and still not complete. does the change of bib source force a reingest? is there any way to delay that, and reingest only the changed bre.id values? |
| 10:31 |
jeff |
mrpeters: check the value of ingest.reingest.force_on_same_marc in config.internal_flag? |
| 10:32 |
jeff |
mrpeters: still, 12 hours is a bit much to reingest 6k bres unless you're on really underpowered hardware. |
| 10:32 |
jboyer-isl |
mrpeters: Even if they are reingested that sounds like an enormous amount of time. Are things otherwise ok with this installation? Otherwise, jeff is right, that flag being set should be the only reason for a reingest if you don't touch the marc field. |
| 10:33 |
mrpeters |
yeah, its a test server, but comparable hardware to production |
| 10:33 |
jboyer-isl |
Stock postgresql.conf or edited? |
| 10:33 |
jeff |
mrpeters: did you do the updates in individual transactions? if not, is there any other activity on the system? have you checked for locking issues? |
| 10:33 |
jeff |
mrpeters: what does postgres think is happening with that query, and any other queries? |
| 10:34 |
mrpeters |
no, im doing one mass update using a staging table that contains one column, record, which = bre.id |
| 10:34 |
mrpeters |
UPDATE bre SET source=101 WHERE id IN (SELECT record FROM staging); |
| 10:36 |
jboyer-isl |
mrpeters: what does the output of this query look like? select * from pg_stat_activity where current_query not like '%<IDLE%'; |
| 10:37 |
mrpeters |
i killed it off, so i expect nothing |
| 10:37 |
|
jboyer_isl joined #evergreen |
| 10:38 |
jboyer_isl |
Well, that should be the case then. I didn't know if you had knocked it out yet or not. |
| 10:38 |
mrpeters |
ah, no, actually looks like there are some nasty hung up queries so that could be the issue |
| 10:38 |
jeff |
ah. we'll disregard, then. next time, i'd recommend ensuring that you're not reingesting if you've no reason to, and if you DO have reason to reingest, don't try to do it all in one transaction unless you are very confident that your database is otherwise completely idle. |
| 10:39 |
Dyrcona |
I'm not sure that changing the source causes a reingest, and it isn't necessary if it doesn't. |
| 10:39 |
Dyrcona |
It will cause a recalculation or opac visibility and some other things. |
| 10:39 |
Dyrcona |
s/or/of/ |
| 10:40 |
mrpeters |
i will need to reingest eventually, because i will also be changing the marc with REGEXP_REPLACE but i hadn't even gotten to that point in the process yet, but, now i see a lot of hung up crap in the db that may take care of things |
| 10:41 |
Dyrcona |
mrpeters: I'd suggest possibly doing whatever you're doing via Perl. I find it much easier to manipulate MARC in Perl than directly in the database. |
| 10:41 |
|
jboyer-isl joined #evergreen |
| 10:41 |
phasefx |
didn't see it in channel this morning (net-split?), but there's a new failure at http://testing.evergreen-ils.org/~live/ re: perl live tests for negative balances |
| 10:42 |
mrpeters |
gotta stick with what i know, for now, Dyrcona |
| 10:42 |
Dyrcona |
pfft. I'm always keen to learn new things. :) |
| 10:43 |
Dyrcona |
But, I get it if you don't think you have the time. |
| 10:45 |
mrpeters |
yeah, time is the issue...and it's just adding a 856$9 to existing records, and regex_replace has never failed me in the past |
| 10:45 |
jeff |
Dyrcona: with ingest.reingest.force_on_same_marc set to true, UPDATE biblio.record_entry SET id = id WHERE id = 1; will cause a reingest of bre id 1. |
| 10:45 |
dbwells |
phasefx: thanks. Looks like two problems. One, do_checkin_override didn't make it into TestUtils, so it was probably missing from the branch. Two, we need to decide how to handle the pre-test SQL. I'll push something in for #1, but am not sure about #2. |
| 10:46 |
mrpeters |
turning off that flag will be key, i think -- i can then build a script to reingest just the records that changed |
| 10:46 |
mrpeters |
system isnt in use, so no harm in having that flag off while i update the few bibs |
| 10:47 |
jboyer-isl |
mrpeters: that flag should be set to false already, you really don't want edits that don't touch the marc to cause a full reingest all the time. You don't have to do anything special to cause a reingest of records whose marc you're editing. |
| 10:47 |
jboyer-isl |
(I'm not sure you can stop it, actually, unless you disable some triggers) |
| 10:48 |
mrpeters |
ah, it may be then...didnt look yet |
| 10:48 |
mrpeters |
i may just be taxing this vm |
| 10:48 |
Dyrcona |
jeff: We leave it off except when we need to use it, then set it and set it back. |
| 10:48 |
mrpeters |
although, i think its better than the old production server |
| 10:49 |
mrpeters |
gonna give it a whirl on the new hardware |
| 10:49 |
Dyrcona |
jeff: I guess I imagined the trigger checked more than it does. :) |
| 10:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Add missing util function for tests - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=437550e> |
| 11:11 |
|
Dyrcona1 joined #evergreen |
| 11:15 |
Dyrcona |
wifi-- |
| 11:35 |
|
bmills joined #evergreen |
| 11:36 |
kmlussier |
New negative balance release notes are in working/user/kmlussier/lp1198465-neg-bal-release-notes However, the assume that bug 1479107 and bug 1479110 are resolved and don't reflect reality yet. |
| 11:36 |
pinesol_green |
Launchpad bug 1479107 in Evergreen "Replace manual void option with an "adjust to zero" option" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479107 |
| 11:36 |
pinesol_green |
Launchpad bug 1479110 in Evergreen "Negative balance settings used in combination with one another should interact differently" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479110 |
| 11:36 |
kmlussier |
So I don't know if we should wait to merge them. |
| 11:39 |
Dyrcona |
We probably should wait. |
| 11:45 |
|
Christineb joined #evergreen |
| 11:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Move negative balance test xacts into sample data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3a6c040> |
| 11:55 |
pinesol_green |
[evergreen|Dan Wells] LP 1198465: Load negative balance test transactions in load_all.sql - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b842239> |
| 11:55 |
|
bmills joined #evergreen |
| 11:56 |
dbwells |
tests should be happier now; we'll see! |
| 11:57 |
jeff |
dbwells++ |
| 11:58 |
kmlussier |
dbwells++ |
| 12:56 |
Dyrcona |
dbwells++ |
| 13:03 |
|
buzzy joined #evergreen |
| 13:41 |
Dyrcona |
@dessert bshum |
| 13:41 |
* pinesol_green |
grabs some Pineapple Upside Down Cake for bshum |
| 13:47 |
|
dMiller joined #evergreen |
| 14:18 |
|
vlewis joined #evergreen |
| 14:20 |
|
ericar_ joined #evergreen |
| 14:26 |
|
ericar_ joined #evergreen |
| 14:36 |
kmlussier |
miker: Did you all ever have any success figuring out how to resolve the keyboard shortcut problems in the web client? |
| 14:37 |
miker |
kmlussier: not yet |
| 14:37 |
kmlussier |
:( |
| 14:53 |
|
vlewis_ joined #evergreen |
| 14:56 |
|
vlewis__ joined #evergreen |
| 15:09 |
mrpeters |
follow up from earlier Re: bib source updates -- ran fine once i cleared out some queries that had hung in this particular test server -- ran in a matter of a couple minutes like I would have expected. |
| 15:11 |
Dyrcona |
mrpeters++ |
| 15:15 |
mrpeters |
for the logs, in case anyone ever needs to add 856$9 tags to e-resource bib records, this works nicely |
| 15:15 |
mrpeters |
UPDATE biblio.record_entry SET marc = REGEXP_REPLACE(marc, $$(<datafield tag="856" ind1="." ind2=".">)(.*?)(</datafield>)$$, $$\1<subfield code="9">SHORTNAME</subfield>\2</datafield>$$, 'g') WHERE id=foo; |
| 15:28 |
bshum |
Dyrcona++ # 2.9 update :) |
| 15:29 |
Dyrcona |
dbwells: I might be able to address the settings in the conditional negative balances code if you don't have time. |
| 15:44 |
dbwells |
Dyrcona: thanks for the offer. I've looked it over, and I think it is more or less a two line change, but I'm not sure we really want to go that way. IMHO, it just makes it equally confusing from the opposite perspective. |
| 15:44 |
Dyrcona |
dbwells: OK, and I think I originally implemented it the way it is, no? |
| 15:44 |
dbwells |
Dyrcona: yes sir |
| 15:45 |
Dyrcona |
You may have changed things since, but I seem to recall it working that way from the start. |
| 15:45 |
dbwells |
The real problem is that Evergreen doesn't have a decent way to manage settings. |
| 15:46 |
dbwells |
It isn't practical to treat every setting as fully independant, and we don't but they sure look that way in our rudimentary interface. |
| 15:47 |
|
jihpringle joined #evergreen |
| 15:48 |
|
mrpeters joined #evergreen |
| 15:49 |
dbwells |
I think the goal of having one or just a few 'master' switches for optional features is sensible and desirable from the code side, but does get confusing from the setting interface side. |
| 15:51 |
dbwells |
Somehow clarifying the options is always a generally good idea, which might mean either better descriptions or renaming. Anyway, just my two cents. |
| 15:53 |
bshum |
gmcharlt: Hmm, that thing on the list for the authors looks like another weird consquence of attrs.authors vs. the graphic_880 grab |
| 15:53 |
gmcharlt |
bshum: not quite; I'm a couple minutes away from emailing an analysis to the list |
| 15:53 |
bshum |
Oh, or maybe how authors.tt2 works for record details? |
| 15:54 |
bshum |
gmcharlt: Okay, I'll eagerly read what you send :) |
| 16:00 |
|
jlitrell joined #evergreen |
| 16:00 |
|
mrpeters joined #evergreen |
| 16:03 |
jboyer-isl |
I wonder if there's time for anyone to poke at bug 1464765 ? It's pretty basic and could go into 2.9/2.8.X pretty easily. Today's Alpha talk reminded me of it. |
| 16:03 |
pinesol_green |
Launchpad bug 1464765 in Evergreen "evergreen.lpad_number_substrings doesn't handle internal substring matches properly" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1464765 |
| 16:14 |
kmlussier |
Dyrcona: No, I don't think you originally implemented them that way. |
| 16:14 |
Dyrcona |
kmlussier: Well, I think I did, but I haven't asked the great Oracle of Git, yet. ;) |
| 16:15 |
* Dyrcona |
is poking at someone else's servers at the moment. |
| 16:22 |
|
remingtron joined #evergreen |
| 16:27 |
jeffdavis |
Dyrcona: I have a couple of other bugs I've been meaning to add to the 2.9 roadmap - they have pullrequest tags in LP and working code in git. Shall I go ahead and do that, or will it create more headaches for you at this point? |
| 16:33 |
Dyrcona |
jeffdavis: You can if you want. Things have been on the roadmap before and missed the release. :) |
| 16:34 |
jeffdavis |
C'est la vie. :) |
| 16:34 |
jeffdavis |
I can also/instead ensure they're targeted at 2.9-alpha if that's easier. |
| 16:34 |
jeffdavis |
(targeted at the 2.9-alpha milestone in LP that is) |
| 16:36 |
* jeffdavis |
goes ahead and does both |
| 16:42 |
kmlussier |
Sorry, I was working on something else. The settings go changed sometime around when comment 28 was added to the bug (see 3a). https://bugs.launchpad.net/evergreen/+bug/1198465/comments/28 |
| 16:42 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 17, heat: 80) [Wishlist,Fix committed] |
| 16:43 |
kmlussier |
But I also recall only setting the interval in my original testing. |
| 16:43 |
kmlussier |
I'm fine with whatever the community decides is more intuitive, but in discussions with the team here, there was general consensus that most people would think that, once people set prohibit to true, they would think it would be prohibited in all cases. |
| 16:45 |
kmlussier |
At the same time, in our environments, there are only a few individuals who would be allowed to touch those settings, so it's not as big of an issue as it would be if it were something most end users would be adjusting on a regular basis. |
| 16:56 |
|
vlewis joined #evergreen |
| 17:13 |
|
mmorgan left #evergreen |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:18 |
dbwells |
yay |
| 17:20 |
bshum |
dbwells++ |
| 17:21 |
|
vlewis_ joined #evergreen |
| 17:31 |
|
dMiller joined #evergreen |
| 17:58 |
|
artunit joined #evergreen |
| 18:34 |
|
sbrylander joined #evergreen |
| 21:41 |
|
akilsdonk joined #evergreen |
| 22:24 |
* bshum |
has too many emails |
| 23:03 |
gsams |
heh |
| 23:33 |
gsams |
server_updates++ |
| 23:33 |
gsams |
huzzah |
