| Time |
Nick |
Message |
| 07:25 |
|
collum joined #evergreen |
| 07:53 |
|
BDorsey joined #evergreen |
| 08:10 |
|
mantis1 joined #evergreen |
| 08:32 |
|
kworstell-isl joined #evergreen |
| 08:33 |
|
jvwoolf joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 09:06 |
|
Dyrcona joined #evergreen |
| 09:32 |
Dyrcona |
Is there an Angular MARCEdit component or does the client still use the AngularJS interface? |
| 09:33 |
Dyrcona |
Ha! There is literally "marc-edit.component.{html,ts}" in eg2/src/app/cat/authority. |
| 09:37 |
Dyrcona |
What I'm really looking for is in Open-ILS/src/eg2/src/app/staff/share/marc-edit/marc-edit.module.ts |
| 09:39 |
mmorgan |
Dyrcona: There's a MARC Edit option in the angular staff catalog from the full record. |
| 09:49 |
Dyrcona |
mmorgan: Thanks! I found the files that I was looking for. |
| 09:51 |
Dyrcona |
CWMARS has a customization to make "Local System" the default source for new bib records. I'm looking at that for the Angular editor. I'm considering adding YAOUS and putting this on Lp, but first, I'm trying to determine if it would be necessary. |
| 10:21 |
|
dguarrac joined #evergreen |
| 11:42 |
Dyrcona |
Libraries need to clear their hold shelves. |
| 11:43 |
mmorgan |
:) |
| 11:48 |
Dyrcona |
I'm not having any luck with the patches for Lp 1971745. I guess my local test system's database is just too slow. Neither patch seems to make a difference for me on an "optimized" database or a default configured database with production data. |
| 11:48 |
pinesol |
Launchpad bug 1971745 in Evergreen 3.9 "Holds shelf list can fail to retrieve results" [Undecided,Confirmed] https://launchpad.net/bugs/1971745 |
| 12:02 |
|
jihpringle joined #evergreen |
| 12:02 |
|
Christineb joined #evergreen |
| 12:33 |
Dyrcona |
The patches are working for me on another development system running 3.7.3.... |
| 12:38 |
Dyrcona |
I wonder if the problem is the other db server, or if something went wrong with the upgrade from 3.7.3 to master? |
| 12:38 |
* Dyrcona |
will test on a 3.7.3 vm with the other db server. |
| 12:49 |
Dyrcona |
Hmm... That system with the "bad" db server won't load a hold shelf with about 9 copies. |
| 12:49 |
Dyrcona |
OK. It loaded on the second try. |
| 13:01 |
Dyrcona |
With or without the patches this other test system can't grab a hold shelf with 100 items. |
| 13:01 |
Dyrcona |
@blame the db server |
| 13:01 |
pinesol |
Dyrcona: the db server is the SPY! |
| 13:28 |
Dyrcona |
This is the server that took 5 minutes to connect cstore, prcrud, and storage last week, so.... |
| 13:30 |
jeffdavis |
That does not sound like a healthy db server. :( |
| 13:47 |
Dyrcona |
Yeah, I know it has 1 bad drive in the array. It might have another bad drive by now. We're going to replace it soon enough. |
| 13:52 |
jeff |
yeah, bad drive in the array = many bets are off. IO may be severely degraded due to RAID type or a handful of other reasons. |
| 13:53 |
jeff |
(though since you say "it might have another bad drive by now", you're probably not dealing with straigt-up RAID-5.) |
| 13:54 |
* Dyrcona |
doesn't remember how the RAID is set up. It has been several years since I last looked at those settings. |
| 13:54 |
Dyrcona |
I'm pretty sure there is some redundancy. |
| 14:23 |
Dyrcona |
The wide_hold_data query is kind of insane. |
| 14:34 |
* mmorgan |
often wonders why some queries are in the perl, some are in the fm_IDL and some are views in the db. What's the best approach? |
| 14:38 |
Dyrcona |
mmorgan: There really isn't a best approach. |
| 14:40 |
Dyrcona |
I'd probably say views in the database used by the IDL, then queries in the IDL, followed by queries in Perl. Views can sometimes be slower than the queries that they're built on, so there is that to consider. |
| 14:41 |
Dyrcona |
Different parts of Evergreen do different things, so... |
| 14:43 |
mmorgan |
Interesting. I didn't realize views could be slower than the queries they're built from. |
| 14:49 |
Dyrcona |
Well, maybe I am wrong about that one. Seeing someone else type it makes me think I said something wrong. However, views can be slow depending on how you construct them, and I know that you can write joins on circ history and the circ table that are faster than using the all_circ view if you leave certain tables in the join. |
| 14:49 |
Dyrcona |
Arg... "leave out certain tables" or "leave certain tables out of the join." |
| 15:20 |
pinesol |
News from commits: LP#1971745 - speed up open-ils.storage.action.live_holds.wide_hash <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e7acf4a00c3948fac5f270926c3838459d57434e> |
| 15:20 |
pinesol |
News from commits: LP#1971745: work around issue that can cause large hold shelf lists to fail <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=1ac2ab4e59cc83292746df731bad708e4a83d662> |
| 15:25 |
Stompro |
Dyrcona, "there's a reason we setup the offline directory twice in our Apache configuration? It's done in eg.conf and again in eg_vhost.conf" I noticed this also, it seemed to be needed when I tried to add a new cgi script, I don't understand why though. |
| 15:25 |
Stompro |
Dyrcona++ thanks for looking at the hold shelf display bug. |
| 15:29 |
Dyrcona |
Stompro: That's interesting about the configuration and the cgi script. I might investigate that. |
| 15:30 |
Dyrcona |
I really wanted to test the hold shelf fixes on Pg 15, but that was on the server that has issues.... |
| 15:38 |
|
jvwoolf left #evergreen |
| 15:41 |
Dyrcona |
Hrm... What version of PostgreSQL should I recommend in the branch that removes Pg 10? I'm inclined to go with Pg 14. |
| 15:41 |
Dyrcona |
Maybe I'll put this branch off until we can have some developer discussion around it. |
| 15:45 |
Stompro |
I don't have any input on that, but I'm looking forward to having a recommendation to follow :-) |
| 15:49 |
Dyrcona |
Well, I'm not sure anyone else will have much to say about that at the next dev. meeting. I'm still inclined to recommend Pg 14, since I've been testing new development on Concerto with that. My latest 2 vms for concerto will use Pg 15 because I used them to develop/test the Pg 15 branch. |
| 15:50 |
berick |
i'm looking at 14 as our next upgrade target fwiw |
| 15:50 |
berick |
and have been using it for dev, etc. |
| 15:50 |
Dyrcona |
I also wonder if we should come up with recommendations for upgrading Pg versions. There are often extra steps required with Evergreen. |
| 15:50 |
Dyrcona |
berick++ |
| 15:55 |
Dyrcona |
Grr. Why do people send screenshots in Word documents? This one actually looked like it was text, and when I tried to click on a barcode to copy and paste it, I find it was actually a screen shot pasted into a docx...... *harrumph* |
| 16:07 |
berick |
a question as old as time |
| 16:10 |
Dyrcona |
:) |
| 16:53 |
Dyrcona |
Weird: we had 1 autorenewal on 11/22 that says it was not an autorenewal.... |
| 16:56 |
Dyrcona |
OK. Looks more like 7 |
| 17:02 |
|
mmorgan left #evergreen |
| 18:53 |
jeffdavis |
I have the impression that there are still a few outstanding performance issues with PG 14, but don't have details. |
