Time |
Nick |
Message |
05:00 |
pinesol |
News from qatests: Failed Running pgTAP tests <http://testing.evergreen-ils.org/~live/test.42.html#2019-01-30T04:57:51,949378057-0500 -0> |
06:52 |
dickreckard |
hello.. I have a question about a swollen database.. |
06:53 |
dickreckard |
I have run a few commands from the postgresql interface, to fix some mess with character encoding that happened during migration.. |
06:53 |
dickreckard |
they were UPDATEs with search and REPLACE on the whole biblio.record_entry ... |
06:54 |
dickreckard |
the character encoding is mostly fixed now, but the database size has grown from ~150mb to 1.2 gb... |
06:55 |
dickreckard |
some table growth i can understand, like the biblio_record_entry_history that went up to ~400mb |
06:56 |
dickreckard |
but some I don't like for example the metabib.real_full_rec which alone is already 200mb.. |
06:57 |
dickreckard |
I think that was probably not the best way to re-ingest the db. but now what do you suggest? |
07:05 |
|
agoben joined #evergreen |
07:38 |
csharp |
dickreckard: you might need to adjust autovacuum settings during large updates/deletes so that doesn't happen |
07:39 |
csharp |
you can run 'VACUUM FULL' on individual tables (locks the table so requires downtime) |
07:40 |
csharp |
basically, postgres reuses rows that normal vacuum reclaims, but if the update/delete process is too fast for autovac to keep up, you'll end up with bloat |
07:41 |
csharp |
vacuum full reclaims the disk space for the OS - conceptually kind of like a Windows defrag |
07:43 |
csharp |
"your library wants you to administer Evergreen? Congratulations, you're also now a PostgreSQL DBA!" |
07:44 |
dickreckard |
ah, thanks a lot for the tip. I will try that! |
07:45 |
jonadab |
csharp: As long as I don't have to admin a Sendmail server, I can live with Postgres. |
07:45 |
csharp |
jonadab++ |
07:49 |
|
tlittle joined #evergreen |
07:54 |
|
rjackson_home joined #evergreen |
08:06 |
|
bos20k joined #evergreen |
08:34 |
|
jvwoolf joined #evergreen |
08:56 |
|
terran joined #evergreen |
08:57 |
|
Dyrcona joined #evergreen |
09:01 |
csharp |
huh - have we not had a rel_3_2_3 yet? |
09:02 |
csharp |
ah - we do, but there's not a branch for it in git |
09:10 |
|
mmorgan joined #evergreen |
09:28 |
|
jamesrf joined #evergreen |
09:30 |
|
jvwoolf joined #evergreen |
09:47 |
|
yboston joined #evergreen |
09:55 |
|
jvwoolf1 joined #evergreen |
10:30 |
mmorgan |
Quick question about autorenewals, max_renewals and max_auto_renewals are both set in the duration rule. I'm assuming max_auto_renewals is a subset of max_renewals? |
10:30 |
gsams |
mmorgan: That's my understanding. max_renewals should be the same or higher than max_auto_renewals. |
10:31 |
mmorgan |
IOW, if max_renewals is set to 2 and max_auto_renewals is set to 2, it means "2 renewals are allowed, one of which will be automatic" |
10:31 |
mmorgan |
Oops, should read max_auto_renewals = 1 |
10:31 |
gsams |
That is how it should work |
10:31 |
mmorgan |
Ok thanks! |
10:32 |
mmorgan |
gsams++ |
10:32 |
gsams |
We are in process of updating to 3.2 today, and I've been patiently waiting to implement this feature |
10:32 |
Dyrcona |
I would assume that them being the same would not be a problem. |
10:32 |
Dyrcona |
That said, I haven't checked the code. |
10:33 |
mmorgan |
gsam: Cool! Are you implementing it across the board? |
10:33 |
mmorgan |
gsams: ^^ |
10:33 |
* mmorgan |
can't type today :-( |
10:34 |
gsams |
mmorgan: No, at least one of our libraries couldn't implement. Though the rest will be using the feature and we agreed on a set number of auto-renewals for the initial setup. |
10:34 |
mmorgan |
I would also assume having them set the same would be fine. |
10:34 |
gsams |
I have plans to increase the max auto renewals in the future though. |
10:36 |
JBoyer |
I have checked the code and it works the way you would hope. :) Including (most importantly for us) it honors the OPAC renewal setting that makes the rewnewal circ lib the same as the checkout circ lib. |
10:38 |
mmorgan |
JBoyer++ |
10:47 |
|
Christineb joined #evergreen |
10:47 |
terran |
JBoyer: We tried implementing that last year, but had to roll it back because we don't allow holds on AV materials between library systems and it was allowing renewals when it shouldn't because there was an available AV item at a different library that couldn't actually be used to fill the hold |
10:49 |
JBoyer |
Huh. I'm surprised that can happen, I assumed that part of the renewal was the same as the existing and would complain. We do transit everything (if the library chooses) so here "it's complicated" :) |
10:49 |
mmorgan |
terran: So it was allowing a renewal that wouldn't be allowed in the staff client? |
10:50 |
mmorgan |
Or by the patron in the opac? |
10:51 |
terran |
Yes - we currently don't allow a renewal if someone else has a hold on the title, even if there are other copies available. When we tried to enable autorenewal, it allowed them to renew if there were holds and other copies available, but sometimes those copies couldn't fill those holds. |
10:53 |
terran |
<there may be some intermediate setting we're overlooking> |
10:59 |
terran |
Wait, sorry, I need more coffee. I was thinking about the hold-ratio settings, not auto-renewal settings. Ignore me, please. |
11:01 |
mmorgan |
@coffee terran |
11:01 |
* pinesol |
brews and pours a cup of Honduras David Mancia, and sends it sliding down the bar to terran |
11:02 |
terran |
much appreciated! |
11:02 |
csharp |
@praise coffee |
11:02 |
* pinesol |
coffee goes to eleven |
11:03 |
csharp |
@blame lack of coffee |
11:03 |
pinesol |
csharp: lack of coffee HAXORED csharp's SERVERZ!!!! |
11:05 |
terran |
<makes note to revisit hold-ratio settings> |
11:06 |
* mmorgan |
also has a note to look at those same settings. |
11:06 |
* csharp |
makes note that terran and mmorgan will be revisiting some settings |
11:07 |
* mmorgan |
also notes that much coffee will be required. |
11:08 |
* gsams |
notes the notable notes being noted. |
11:08 |
csharp |
unless ($coffee) { die; } |
11:08 |
berick |
@coffee csharp (quickly) |
11:08 |
JBoyer |
while (1) { note; } |
11:08 |
* pinesol |
brews and pours a cup of Panama El Burro Estate, and sends it sliding down the bar to csharp (quickly) |
11:09 |
mmorgan |
csharp: That needs to be on a t-shirt. |
11:09 |
csharp |
berick++ # saving lives |
11:25 |
gsams |
Does hatch for firefox need any testing still? I'd like to try it out if it's in a state for that. |
11:26 |
dickreckard |
csharp: thanks a lot, vacuuming and cleaning up the record_history worked |
11:26 |
dickreckard |
csharp++ |
11:27 |
dickreckard |
another thing I encountered though, is there a way to cleanup the metabib.browse_entry? it seem to keep the entries for each modification of a record.. |
11:32 |
|
jvwoolf joined #evergreen |
11:36 |
|
beanjammin joined #evergreen |
11:41 |
berick |
dickreckard: there is.. |
11:41 |
berick |
i have a bit of sql |
11:41 |
miker |
dickreckard: a query can be constructed, but because the entries might be in use by either bibs /or/ authorities, it's not automatic (too expensive to put in the main ingest code) |
11:41 |
* berick |
looks |
11:43 |
pastebot |
"berick" at 64.57.241.14 pasted "browse cleanup SQL" (9 lines) at http://paste.evergreen-ils.org/14395 |
11:43 |
berick |
i haven't run that exact variation, but I think it'll work |
11:50 |
dickreckard |
aaah yes I was looking at this map. fantastic! thanks :) |
11:54 |
dickreckard |
berick++ |
11:57 |
|
khuckins joined #evergreen |
11:58 |
JBoyer |
gsams, I believe it's missing only a signoff. it's not especially difficult to build if you'd like to throw some tuits at that. |
11:59 |
gsams |
JBoyer: I might just have some tuits to throw that way. |
11:59 |
JBoyer |
gsams++ |
12:00 |
JBoyer |
Let me know if you run into any issues building it; it's been a bit but I've messed with it a fair bit. |
12:02 |
|
jihpringle joined #evergreen |
12:14 |
JBoyer |
So is anyone else having issues building a recent eg2 staff client because of errors in rxjs? |
12:18 |
berick |
JBoyer: hm, no, new build? |
12:19 |
* berick |
runs npm update |
12:19 |
JBoyer |
From a fresh checkout, anyway. I was just updating a machine that has had recent Eg versions on it for some time. |
12:20 |
berick |
oh, I just to them |
12:20 |
berick |
after updating |
12:21 |
* berick |
tries a full rebuild |
12:21 |
JBoyer |
Oh, I just ran npm update and I see that it updated angular/compiler-cli, that may take care of it too. (it's complaining about syntax errors, ';' expected here and there) |
12:21 |
berick |
yeah |
12:23 |
JBoyer |
Hmm. except my normal build also calls npm update. Not sure why that didn't catch it earlier. :/ |
12:25 |
JBoyer |
And now it's complaining about jasmine. I guess I'll keep looking. |
12:26 |
berick |
i'm testing some hard-coded versions |
12:27 |
berick |
related, we really need to merge bug 1801984 sooner than later |
12:27 |
JBoyer |
bot is letting us down. |
12:28 |
pinesol |
Launchpad bug 1801984 in Evergreen "Transition to Angular version 7." [Undecided,New] https://launchpad.net/bugs/1801984 |
12:28 |
JBoyer |
Ah. |
12:31 |
berick |
rxjs in particular has a lot of changes and we currently have a compat library installed to handle them |
12:31 |
berick |
but the Ang 7 stuff removes the compat layer |
12:32 |
berick |
JBoyer: I got it to build by making 2 changes to package.json |
12:32 |
berick |
"ngx-cookie": "4.0.2" # avoids the cookie warnign that sometiems pops up |
12:32 |
berick |
"rxjs": "6.3.2" |
12:32 |
berick |
then wiped and rebuilt node_modules |
12:33 |
* berick |
probably needs to rebase the ang7 stuff, it's been sitting a while |
12:33 |
csharp |
whoa, the SELECT subquery from berick's metabib.browse_entry cleanup SQL returns 2687555 rows |
12:33 |
* csharp |
charges up his VACUUM |
12:33 |
berick |
heh |
12:35 |
csharp |
dickreckard: glad my advice was useful :-) |
12:45 |
gsams |
JBoyer: I don't think my computer wants me to compile this thing. I'm getting package does not exist/cannot find symbol errors for all of the JSON. |
12:46 |
JBoyer |
gsams, JSON? or Java? |
12:46 |
gsams |
everything is showing JSON |
12:46 |
JBoyer |
You don't need to actually build the extension part, only the Windows installer part; The FF addon site already has that code. |
12:47 |
|
sandbergja joined #evergreen |
12:48 |
* JBoyer |
managed to break npm on this machine in a most spectacular fashion. |
12:50 |
Dyrcona |
JBoyer: Did you upgrade it when it suggested that you do that? |
12:50 |
* Dyrcona |
has broken it that way. |
12:50 |
* csharp |
gets frustrated when the solution to a nodejs problem is "downgrade npm" |
12:50 |
JBoyer |
No, I thought "maybe the Angular 7 compiler will like this code more." Then I uninstalled it and now I'm blowing away everything and starting from scratch. |
12:51 |
csharp |
I had that issue when building the Linux client for Google Music Desktop Player |
12:51 |
JBoyer |
berick, when you have time to rebase that branch I will test it asap. |
12:52 |
berick |
JBoyer: doing so now. and after a rebuild, errors are clear |
12:54 |
berick |
JBoyer: LP updated |
12:54 |
JBoyer |
berick++ |
12:56 |
gsams |
JBoyer: Ah, yes I think I see what I was doing wrong. I misunderstood the readme. |
13:08 |
Dyrcona |
berick: What is your threshold for merging Ang 7 into master? |
13:11 |
berick |
Dyrcona: threshold? |
13:11 |
Dyrcona |
Yeah, like how many signoffs, how many tests, etc.? |
13:12 |
berick |
oh, i don't see it as any different than a feature merge. (though it's almost a bug fix merge at this point). as long as the existing tests pass (they do) then I think the tests are covered. |
13:13 |
berick |
it doesn't introduce new code, mostly just changes to how we import certain libraries |
13:13 |
berick |
rxjs being the big upheaval |
13:13 |
berick |
oh, and, the UI should work ;) |
13:14 |
Dyrcona |
So, should it be backported to 3.2? |
13:14 |
berick |
maybe.. |
13:14 |
berick |
let me see if it merges/builds in 3.2 |
13:15 |
JBoyer |
That's basically what I'm doing now. :) I pulled it in to our locally customized rel_3_2 |
13:16 |
Dyrcona |
I was going to say that I could test it with rel_3_2. |
13:16 |
JBoyer |
And everything looks good so far. Almost ready to start with the clicky-clicky. |
13:16 |
Dyrcona |
:) |
13:16 |
berick |
Dyrcona: for 3.2 backport, an extra test/signoff would certainly be appreciated |
13:17 |
berick |
since we want to avoid disruption |
13:17 |
berick |
and we don't normally back-port version upgrades |
13:18 |
berick |
3.2 is working fine for me |
13:18 |
berick |
no big surprise, there's very little code deviation yet between master |
13:19 |
* berick |
updates LP |
13:19 |
Dyrcona |
berick++ JBoyer++ |
13:20 |
JBoyer |
Nice. |
13:20 |
JBoyer |
berick++ |
13:20 |
JBoyer |
signoff en route. |
13:20 |
berick |
JBoyer++ Dyrcona++ |
13:22 |
|
beanjammin joined #evergreen |
13:37 |
Dyrcona |
It will likely be couple of hours before I can look at it, but I'll endeavor to get to it by tonight. |
13:42 |
|
jvwoolf joined #evergreen |
14:06 |
|
yboston joined #evergreen |
14:47 |
|
jamesrf joined #evergreen |
15:03 |
|
nfBurton joined #evergreen |
15:50 |
jamesrf |
when I turn on "Store Offline Transaction Data in Hatch" it doesn't seem to ever actually do this. It sets eg.hatch.enable.offline but it doesn't seem to store any xacts in the hatch ~/.evergreen dir after I've logged out, restarted browser, etc. -- is there something I'm doing wrong? tried on both a sitka server and demo.evergreencatalog.com |
15:53 |
berick |
jamesrf: it was never implemented. offline has only ever been stored in indexeddb |
15:54 |
jamesrf |
if it was never implemented why is there a functioning checkbox for it? |
15:54 |
berick |
that option is gone in current 3.2 |
15:54 |
jamesrf |
ok thanks |
16:06 |
gsams |
JBoyer: Okay, so I've got hatch enabled and running, but firefox doesn't see any printers. |
16:07 |
|
jonadab joined #evergreen |
16:12 |
|
Dyrcona joined #evergreen |
16:15 |
gsams |
JBoyer: That appears to be the case in both browsers though, so I suspect that's my fault. I'll double back on it for the moment. |
16:26 |
|
book` joined #evergreen |
17:00 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
17:06 |
|
mmorgan left #evergreen |
17:23 |
gsams |
Post install note: refresh the page |
17:23 |
gsams |
only thing that hasn't fixed for me is hatch. |
17:30 |
Dyrcona |
berick++ Angular 7 is working for me on an "upgrade" of a VM from master to master. |
17:32 |
berick |
cool |
17:33 |
Dyrcona |
The UI looks good. I've run the Angular and AngularJS tests, Running perl live tests now, just to be sure. |
17:35 |
Dyrcona |
berick: So, it's OK with you if I signoff and push it to master and 3.2? |
17:40 |
berick |
Dyrcona: yes |
17:41 |
Dyrcona |
All right, then, I will do that. |
17:42 |
|
jvwoolf left #evergreen |
17:49 |
pinesol |
[evergreen|Bill Erickson] LP#1801984 Upgrading Angular 6 to Angular 7 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7e2483b> |
18:01 |
gsams |
JBoyer: So I went back and started over, as I was having an issue seeing printers in both Chrome and Firefox. Now I can't get installer to compile at all. It's giving me an error on line 175. |
20:27 |
gsams |
JBoyer:Final note, for whatever reason when I went to retry the process, the lib folder wasn't present anymore. I ported it over from the precompiled installer, just to get it going. It appears to work properly now. |
20:28 |
gsams |
I'm just a tad bit out of my depth on this one, so I'm not really sure what went wrong. It was there the first time I cloned the branch, but then it wasn't the next time. |
20:29 |
gsams |
In any case, I'm about to sign off on it as I've gotten it to work in Firefox. |
20:53 |
gsams |
strike that, I thought berick had done the Chrome testing, and my gut says to wait. |
20:53 |
gsams |
since my chrome appears to not be working, so maybe I either did something else wrong. |
20:54 |
gsams |
or something did break. |
21:30 |
|
jamesrf joined #evergreen |
23:41 |
|
sandbergja joined #evergreen |