| Time |
Nick |
Message |
| 04:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:16 |
|
rjackson_isl joined #evergreen |
| 07:27 |
|
bdljohn joined #evergreen |
| 07:53 |
|
agoben joined #evergreen |
| 08:17 |
|
bos20k joined #evergreen |
| 08:19 |
JBoyer |
csharp++ # Getting your name on the CotM plaque. |
| 08:24 |
csharp |
JBoyer: thanks! |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:45 |
|
mdriscoll joined #evergreen |
| 08:51 |
|
Dyrcona joined #evergreen |
| 08:51 |
|
aabbee joined #evergreen |
| 09:10 |
Dyrcona |
@later tell yboston The problem is that there is no way to match subfields to a particular field in metabib.full_rec, nor in the table metabib.real_full_rec. I recommend pulling out the marc from biblio.record_entry and extracting the fields with XPATH or using the MARC::Record Perl module. |
| 09:10 |
pinesol |
Dyrcona: The operation succeeded. |
| 09:14 |
|
yboston joined #evergreen |
| 09:26 |
|
jvwoolf joined #evergreen |
| 09:43 |
|
stephengwills joined #evergreen |
| 09:48 |
stephengwills |
i’m trying to import some marc21xml using the staging_importer function from the 3.1/command_line_admin/_migrating_your_bibliographic_records documentation. this funtion is returning the error SSL Syscall error: EOF detected. Has anyone else run into this? |
| 09:51 |
stephengwills |
for the record: just found this from Dan Wells: https://bugs.launchpad.net/evergreen/+bug/1053397 in 2014. some kind of memory error. |
| 09:51 |
pinesol |
Launchpad bug 1053397 in Evergreen "TPAC - Missing Meta-record Level Hold" [Wishlist,Fix released] |
| 10:06 |
|
jvwoolf1 joined #evergreen |
| 10:06 |
stephengwills |
yup…seg fault on 8G test server. will increase RAM and try again. |
| 10:12 |
miker |
csharp: re your log from last night, the cstore backends are timing out waiting for a request, which means that storage (the inner-most search stuff) is doing something for longer than 6 seconds ... cstore itself isn't timing out. it could very well be the container filter code... is that a big container? |
| 10:19 |
miker |
hrm... looking at the code, I don't like that theory anymore :( |
| 11:14 |
|
collum joined #evergreen |
| 11:28 |
|
khuckins joined #evergreen |
| 11:31 |
yboston |
sandbergja++ for the SQL help she posted yesterday for me |
| 11:40 |
|
Christineb joined #evergreen |
| 11:53 |
|
sandbergja joined #evergreen |
| 12:03 |
pinesol |
[evergreen|Jane Sandberg] LP1808268: Add [disable] option to <eg-grid-toolbar-action> in eg2 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=44d4238> |
| 12:03 |
pinesol |
[evergreen|Bill Erickson] LP#1808268 eg2 grid rename action disable option - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9776fd8> |
| 12:09 |
|
jihpringle joined #evergreen |
| 12:13 |
pinesol |
[evergreen|Bill Erickson] LP1808268 eg2 grid action disableOnRows sanity check - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=795c2f3> |
| 12:21 |
csharp |
miker: here's another example of something where cstore stops waiting: https://pastebin.com/2U201g0c |
| 12:22 |
csharp |
my next step is to kick up the loglevel on our test server to see what it shows, but I'm consumed with personal stuff today, so it will need to be later |
| 12:24 |
csharp |
stephengwills: make sure to rule out bug 1764542 |
| 12:24 |
pinesol |
Launchpad bug 1764542 in Evergreen "Incorrect format on config.metabib_field insert results in segmentation fault" [High,Fix released] https://launchpad.net/bugs/1764542 |
| 12:24 |
* csharp |
disappears again |
| 12:37 |
|
yboston joined #evergreen |
| 12:39 |
berick |
csharp: when you return, I think miker is on the money |
| 12:39 |
berick |
what I think is happening is in load_myopac_bookbags |
| 12:39 |
berick |
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/WWW/EGCatLoader/Account.pm;h=d78b59bf5fee58fcbdb1cb90c9703aac39551f43;hb=HEAD#l2316 |
| 12:40 |
berick |
2333 start cstore transaction |
| 12:40 |
berick |
2361 cstore call in logs for cbreb... |
| 12:40 |
berick |
2382 multiclass query call -- potentially runs longer than 6 seconds |
| 12:40 |
berick |
followed by various commits/rollbacks depending on requested action. |
| 12:41 |
berick |
cstore xact needs to be closed before the long-running call, then re-opened as necessary |
| 12:41 |
Dyrcona |
Does it even need to be opened at that point? |
| 12:42 |
berick |
Dyrcona: looks like it was added to fight replication issues, so I'm assuming yes |
| 12:43 |
Dyrcona |
OK. |
| 13:23 |
|
nfBurton joined #evergreen |
| 13:27 |
|
jamesrf joined #evergreen |
| 13:33 |
|
jvwoolf joined #evergreen |
| 13:43 |
csharp |
berick: how do you close the xact? |
| 13:44 |
csharp |
berick++ #btw |
| 13:46 |
JBoyer |
csharp, if it's not actually making an edit that needs to be kept I assume something like $e->rollback or similar before the multiclass call should do it. |
| 13:46 |
berick |
csharp: $e->rollback; |
| 13:46 |
berick |
yeah |
| 13:46 |
berick |
key is it will have to be re-opened before the call to $self->_update_bookbag_metadata |
| 13:53 |
JBoyer |
berick++ # I forgot why there was a xact in the first place. That would have been annoying to track down |
| 13:54 |
* csharp |
tries it |
| 13:57 |
csharp |
ok -it appears to work fine - takes for-freaking-ever, but eventually loads |
| 14:00 |
JBoyer |
Sounds like there's a bad plan somewhere that's taking way longer than it should, but at least you don't get an ISE thrown at you anymore. |
| 14:07 |
csharp |
yeah - exactly - fix the slowness next/later |
| 14:36 |
|
Stompro joined #evergreen |
| 14:57 |
Stompro |
Hello, does anyone happen to know if the 3.1 or 3.2 releases of evergreen still have issues with not indexing ampersands? |
| 14:59 |
miker |
Stompro: I believe neither will. nor will they index a pipe | AFAIR, because those are search operators. that could probably be worked around with an index normalizer to map & and | to something else, like _and_ or _pipe_, but I haven't tried that personally |
| 15:02 |
Stompro |
Thanks Miker, I don't think we have ever had an issue with someone needing the | character, we just have people try and search using "and" when the heading uses "&". We have been putting in alternate titlles for the ones in titles, but I just noticed that a series search failed for the same reason. |
| 15:03 |
Stompro |
I'm not sure I really want to add alternate series entries since that will increase the number of series facets. |
| 15:04 |
Stompro |
I'll look into the mapping route. |
| 15:19 |
mmorgan |
Stompro: We've had this issue as well. We tried putting & in our synonym dictionary but that didn't work. I'd be interested in what you come up with. |
| 15:22 |
Stompro |
mmorgan, we ran into the same thing, but since the & never hits the index, it cannot be processed. |
| 15:32 |
miker |
Stompro: just make sure your index normalizer has a position > 0 so that it doesn't change the displayed values |
| 15:33 |
miker |
if you go that route |
| 15:34 |
Stompro |
miker, are you a mind reader, i was just looking at that field. |
| 15:42 |
Stompro |
Hmm, i tried just simply substituting & for and in the normalizer, and that seems like it does it in my quick testing. Miker, is there a reason I need to map & to _and_ vs just to 'and'; |
| 15:43 |
Dyrcona |
tsqueries, maybe? |
| 15:43 |
Dyrcona |
but, maybe not. |
| 15:45 |
Stompro |
we already have a synonym for and -> &, so with that change both & and 'and" exist in the series_field_entry index_vector, but the series_field_entry value does now have and vs &. |
| 15:47 |
miker |
Stompro: no reason, really. does searching for & also work then? |
| 15:52 |
Stompro |
miker, it seems like it does, but it could just be filtering out the &, the results with or without the & included seem to work. It does change the relevance ranking for the couple that I've reindexed since making the change. |
| 15:52 |
|
yboston joined #evergreen |
| 15:56 |
Stompro |
When I remove the "&" in the series from one of the items I'm testing, that title still comes up for a search with or without '&' included, but not when 'and' is used. So I think the & is being ignored. |
| 15:57 |
Stompro |
Which is fine, I just want the 'and' searches to work. |
| 16:08 |
|
jamesrf joined #evergreen |
| 16:31 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 16:36 |
Stompro |
miker, hmm, searches with quotes around them, exact match, won't work with this method... |
| 16:38 |
Stompro |
The advanced search, exact match option does still work though. |
| 16:45 |
Bmagic |
Did I see a bug (can't find it now) that said that deleting patron using user buckets does NOT remove the patron data? |
| 16:47 |
mmorgan |
Bmagic: Deleting patrons in a bucket sets the deleted flag only, it does not purge user data. Not sure if there's a bug. |
| 16:47 |
Bmagic |
ah! That's what I thought |
| 16:47 |
Bmagic |
mmorgan++ |
| 17:07 |
|
mmorgan left #evergreen |
| 19:47 |
|
nfBurton joined #evergreen |
