| Time |
Nick |
Message |
| 06:57 |
|
agoben joined #evergreen |
| 07:09 |
|
rjackson_isl joined #evergreen |
| 07:21 |
|
collum joined #evergreen |
| 08:09 |
|
Dyrcona joined #evergreen |
| 08:31 |
|
bos20k joined #evergreen |
| 09:15 |
|
nfBurton joined #evergreen |
| 09:17 |
|
stephengwills joined #evergreen |
| 09:24 |
|
jvwoolf1 joined #evergreen |
| 09:25 |
|
yboston joined #evergreen |
| 09:49 |
Stompro |
Good morning everyone, can anyone confirm that the whole preferred lib feature (including results from home library in addition to search lib settings) was removed with the searching rewrite? We used to exploit that to show ebook results for a certain system even when the consortium was selected for search lib. |
| 09:59 |
csharp |
I've been a bit tuned out of EG development over the last few months, but I wasn't aware of a searching rewrite :-/ |
| 10:02 |
Stompro |
We are moving from 2.10 to 3.3 so my sense of time may be off :-) let me find more info on the search rewrite I'm talking about. |
| 10:02 |
Stompro |
So many new things at once. |
| 10:04 |
berick |
and here I thought going from 2.12 -> 3.2 was a big upgrade. |
| 10:05 |
* jeff |
grins |
| 10:05 |
* gmcharlt |
is mildly curious whether any 1.x systems are still around |
| 10:05 |
Stompro |
Yah, we have promised staff that we will upgrade more often from now on. |
| 10:05 |
gmcharlt |
lurking quietly |
| 10:05 |
csharp |
oh wow - yeah - almost a totally different product |
| 10:06 |
gmcharlt |
very quietly |
| 10:06 |
csharp |
gmcharlt: so quiet |
| 10:06 |
csharp |
"total silence" |
| 10:07 |
csharp |
I've never seriously tried it, but I think a cool experiment would be to try to get a 1.X system installed - especially the pre-autotools versions :-) |
| 10:07 |
Stompro |
Ok, so rewrite = the not at all recent 3.0 "eliminate staged search" bug #1698206. |
| 10:08 |
pinesol |
Launchpad bug 1698206 in Evergreen "Eliminate staged search" [Wishlist,Fix released] https://launchpad.net/bugs/1698206 |
| 10:10 |
gmcharlt |
I have created a 3.5 series and 3.5-alpha milestone in LP |
| 10:11 |
gmcharlt |
to serve for bug targetting; easy to rename them later if desired |
| 10:11 |
* berick |
makes use of it |
| 10:12 |
|
sandbergja joined #evergreen |
| 10:14 |
csharp |
sandbergja: the wall of text on the commit message of https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=1d4e2ade866902a4bf118104c49a2958f025d0c4 may have your answers |
| 10:14 |
csharp |
sorry Stompro , not sandbergja |
| 10:21 |
|
jvwoolf joined #evergreen |
| 10:22 |
|
Dyrcona joined #evergreen |
| 10:26 |
Dyrcona |
Well, this is crazy: An update of 1,198 bib records ran much faster on a Pg10 database that is using default settings than it did on a Pg9.6 database using optimized settings on the same server, I mean like 10 orders of magnitude faster. |
| 10:27 |
Dyrcona |
Both have had statistics recalculated. I suppose running it once isn't much of a test, but.... |
| 10:29 |
Dyrcona |
Well, "10 order of magnitude" should be more like 10x.... |
| 10:30 |
csharp |
that's encouraging |
| 10:30 |
Dyrcona |
And unrelated to Evergreen: Ubuntu 19.10 hasn't resolved my WiFi issues with the mismatched protocols.... |
| 10:31 |
Dyrcona |
I suppose that is encouraging, and maybe I'll just upgrade us to Pg10 in production instead of 9.6. |
| 10:31 |
Dyrcona |
Both database were upgraded from Pg 9.5, as an additional data point. |
| 10:38 |
csharp |
good to know - we're running 3.4 on PG11 in a test environment, but I plan to target 10 on the next reinstall |
| 10:39 |
Dyrcona |
I've got Pg 11 on this server, too. Other than doing pg_upgrade, I've not messed with it. |
| 10:39 |
Dyrcona |
9.5, 9.6, 10, 11 on the same server |
| 10:40 |
Dyrcona |
Old mail servers with 6TB of disk space make decent test DB servers. :) |
| 10:55 |
Stompro |
Thanks csharp, I don't see any mention of the preferred lib feature in the commit message. And looking at the code I cannot tell if the @pref_ou is no longer passed as part of the search, or if it just gets included in a way that I cannot see when sent to the database. |
| 11:03 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 11:08 |
pinesol |
[evergreen|Josh Stompro] LP#1555791 - Hide Print List from checkout screen - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8195d83> |
| 11:08 |
pinesol |
[evergreen|Galen Charlton] LP#1555791: add release notes entry - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7a4dd11> |
| 11:11 |
|
collum joined #evergreen |
| 11:32 |
|
nfBurton joined #evergreen |
| 11:33 |
|
Christineb joined #evergreen |
| 11:34 |
jeffdavis |
Stompro: looks to me like preferred library holdings are listed first (when available) in our 3.3.4 environment. Is it not working for you? |
| 11:35 |
Stompro |
jeffdavis, it's the ebooks (scoped 856) that don't seem to show up for us. |
| 11:35 |
jeffdavis |
ah |
| 11:36 |
Stompro |
We want consotium search by default, with a preferred lib of a specific system, so all physical items for the consortiume show up, but only ebooks for a specific system. |
| 11:38 |
jeffdavis |
On ebooks with multiple 856's in search scope, I see the preferred library's 856 on results if it exists. |
| 11:39 |
jeffdavis |
I don't think pref lib will affect search results though? It just affects display of holdings (and I guess 856 display) on the records that would be in your result set anyway. |
| 11:40 |
jeffdavis |
(also that 856 behavior could be a local customization, we did some tweaking of located URIs and I don't think all of it has made it upstream) |
| 11:42 |
nfBurton |
856$9 designates the visibility. I have it set to system wide for my libraries but you could change those to a specific library for them to show only for that library |
| 11:43 |
|
sandbergja joined #evergreen |
| 11:44 |
Stompro |
jeffdavis, we also had a small local change to decouple the search lib with the pref lib, so when users log into their accounts, they still search consortium by default. |
| 11:49 |
|
rfrasur joined #evergreen |
| 12:03 |
Stompro |
nfBurton, we do have our 856$9's set for the owning system. On 2.10, a search would include located URI records based on the preferred search lib, no matter what the search lib is set to. I can log in to my account, which sets the preferred lib to by home library in system A, then I can change my search lib to system B , branch 1 and I will get copies for System B, Branch 1, but ebooks for system A. |
| 12:09 |
Stompro |
jeffdavis, I just tested and you are correct about pref lib not effecting physical holdings, I was wrong about that. But it did include the ebook records (on the 2.10 system). |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:12 |
Stompro |
Interesting, on 3.3.4, I'm able to see both sets of 856 links (one scoped for system A, one for system B) if I have a preferred lib for system A and and search lib for system B. |
| 12:15 |
Dyrcona |
Stompro: Did you update the bib record vis attr field during the upgrade? |
| 12:15 |
Dyrcona |
I think that's what it's called. |
| 12:17 |
Dyrcona |
biblio.record_entry.vis_attr_vector, there's a skippable part of the upgrade to update this filed, and it sounds like your issues *may* be related to that. |
| 12:20 |
Stompro |
Yes, it is populated, and the visibility seems to work fine in general for physical copies. And ebooks show up fine if the search lib equals the 856$9 location. We just want customers to be able to see all physical copies in the consortium, and only ebook links that they can access. |
| 12:21 |
Stompro |
(I'm sure that the answer is use Depth somehow, I just also want to avoid another knob visible that is going to confuse staff and customers.) |
| 12:27 |
dbs |
Ah, so search scope is set to CONS and 856$9s from SYS1/SYS2 aren't showing up? I think that might be by design; the way electronic resources were included in search scopes was flipped |
| 12:30 |
* dbs |
looks at https://bugs.launchpad.net/evergreen/+bug/1623974 and wonders if that kinda-sorta matches Stompro's issue |
| 12:30 |
pinesol |
Launchpad bug 1623974 in Evergreen "Electronic resources behave like copies setting does not act as expected with depth searches" [Medium,New] |
| 12:35 |
dbs |
https://bugs.launchpad.net/evergreen/+bug/975577 was code that I wrote for 2.2 to enable pref_lib to include located URIs from the pref_lib when it is outside of the search scope |
| 12:35 |
pinesol |
Launchpad bug 975577 in Evergreen "Preferred library should affect search scope for located URIs" [Undecided,Fix released] |
| 12:35 |
|
collum joined #evergreen |
| 12:35 |
Stompro |
dbs, I actually wouldn't want the wanted behavior from that bug. If we give the catalog a hint of what system or branch a patron or catalog instance belongs to (via home_ou = pref_ou logic for logged in users, or via apache physical_loc directive) then only show them ebooks that they can actually access. |
| 12:35 |
dbs |
that last one was commit: 0796460961b510e385437c89bd4bf0b9a5ea7f77 |
| 12:35 |
pinesol |
dbs: [evergreen|Dan Scott] Add pref_ou query filter for preferred library searching - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0796460> |
| 12:36 |
dbs |
Stompro: right, that makes sense to me |
| 12:36 |
dbs |
so it sounds like there may have been a regression since 0796460961b |
| 12:36 |
pinesol |
dbs: [evergreen|Dan Scott] Add pref_ou query filter for preferred library searching - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0796460> |
| 12:37 |
|
yboston joined #evergreen |
| 12:38 |
|
khuckins joined #evergreen |
| 12:44 |
Stompro |
dbs, thanks for the pointers... I'm trying to understand if the search.query_parser_fts is even used anymore in 3.3? |
| 12:59 |
|
yboston joined #evergreen |
| 13:29 |
|
sandbergja_ joined #evergreen |
| 13:58 |
|
bos20k joined #evergreen |
| 14:33 |
|
khuckins joined #evergreen |
| 14:50 |
* Stompro |
gives up on trying to follow the search code path. |
| 15:00 |
|
jvwoolf joined #evergreen |
| 15:14 |
jeffdavis |
Stompro: pretty sure the search.query_parser_fts db function is dead code since 3.0 (bug 1698206). I don't see it being called anywhere in 3.3. |
| 15:14 |
pinesol |
Launchpad bug 1698206 in Evergreen "Eliminate staged search" [Wishlist,Fix released] https://launchpad.net/bugs/1698206 |
| 15:15 |
Stompro |
Thanks jeffdavis |
| 15:18 |
jeffdavis |
bug 1831803 proposes removing some other stale search db stuff, maybe that should be expanded to remove search.query_parser_fts too (it's still installed, just not used afaict) |
| 15:18 |
pinesol |
Launchpad bug 1831803 in Evergreen "asset.opac_visible_copies is unused and should be removed" [Low,Confirmed] https://launchpad.net/bugs/1831803 |
| 15:21 |
jeffdavis |
speaking of which, I have some work to do on that bug |
| 15:21 |
jeffdavis |
... and I see my branch already removes search.query_parser_fts |
| 15:30 |
jeff |
"I already removed the donuts!" |
| 16:33 |
Stompro |
jeffdavis, I think a bunch of those $param_* variables were only used by search.query_parser_fts also in metabib.pm. |
| 16:34 |
Stompro |
my precious $param_pref_ou doesn't seem to be used anywhere else... how do I hook that back in??? |
| 16:41 |
jeffdavis |
Stompro: looking at _get_pref_lib in OpenILS/WWW/EGCatLoader/Util.pm and the use of pref_lib as a param in Open-ILS/src/sql/Pg/990.schema.unapi.sql, seems like pref lib still ought to be respected |
| 17:03 |
Stompro |
So does Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/QueryParser.pm build the search query? It seems like the logic in search.query_parser_fts for dealing with the pref_lib, to add in located_uri records isn't in QueryParser.pm |
| 17:06 |
Stompro |
The commit that dbs mentioned, https://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0796460 doesn't seem to touch 990.schemal.unapi.sql |
| 17:06 |
pinesol |
Stompro: [evergreen|Dan Scott] Add pref_ou query filter for preferred library searching - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0796460> |
| 17:06 |
jeffdavis |
That commit predates 3.0 when search changed under the hood. |
| 17:06 |
jeffdavis |
so I assume anyway, judging from the commit timestamp |
| 17:12 |
Stompro |
Yes, I'm just trying to spot where in the "Eliminate staged search" commit the pref_lib located URI feature is implemented. If it still exists then I should be able to spot where it is used. It used to be passed to search.query_paerser_fts as an argument. |
| 17:19 |
|
jvwoolf left #evergreen |
| 17:28 |
Stompro |
I see where the uri as copy global flag gets used in QueryParser, https://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Storage/Driver/Pg/QueryParser.pm;hb=HEAD#l1482 |
| 17:28 |
Stompro |
I wonder if there needs to be a section that checks for pref_lib and inserts pref_lib and descendents into the luri_org visibility attribute test. |
| 18:07 |
jeffdavis |
It seems like query parsing ignores pref lib in 3.0+. AFAICT pref lib does not affect which records are included in search results (pref lib is not silently added to your search scope), it only affects display of holdings/located URIs on whatever records are already in the result set. I think it's debatable whether this behavior is correct. |
| 18:07 |
jeffdavis |
It's different from pre-3.0 but I don't know if I necessarily want to see Library A results if I have selected Library B as my search scope. |
| 18:07 |
jeffdavis |
(different from luri's at least) |
| 18:08 |
jeffdavis |
hopefully someone who understands search better can weigh in if I'm wrong :) |
| 18:10 |
|
sandbergja_ joined #evergreen |
| 18:24 |
|
stephengwills left #evergreen |
| 19:49 |
|
sandbergja joined #evergreen |
| 21:17 |
|
sandbergja joined #evergreen |
| 22:58 |
|
remingtron joined #evergreen |
| 22:58 |
|
dbwells_ joined #evergreen |
| 23:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
