| Time |
Nick |
Message |
| 08:04 |
|
collum joined #evergreen |
| 08:34 |
|
mantis joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 09:03 |
|
dguarrac joined #evergreen |
| 09:52 |
csharp_ |
@band add Mother Bucket |
| 09:52 |
pinesol |
csharp_: Band 'Mother Bucket' added to list |
| 10:39 |
Bmagic |
csharp_: did you (or anyone for that matter) figure out a fix for the coded_value_map table post-3.13? |
| 10:40 |
Bmagic |
I'm considering truncating the table and all linked tables, and re-inserting stock data from 3.13 950.data.seed-values.sql |
| 10:41 |
Bmagic |
(on an already-upgraded database). In other words: passed the point of no return |
| 10:48 |
berick |
i'm not up to date on the coded_value_map issues, but it seems like a reingest would fix the data there? |
| 10:53 |
csharp_ |
Bmagic: in the end I decided to just skip the whole thing by commenting out the thousands of lines for that DB change |
| 10:53 |
Bmagic |
ok, that's what I thought you said |
| 10:58 |
|
sandbergja joined #evergreen |
| 10:59 |
berick |
csharp_: mind pointing me at what you commented out? |
| 10:59 |
* berick |
will be going down this road shortly |
| 11:00 |
Bmagic |
probably the whole 1433 (or whichever DB number) block |
| 11:01 |
csharp_ |
Bmagic: berick: https://git.evergreen-ils.org/?p=evergreen/pines.git;a=commit;h=4e27fc0ae5790ab71606e20cae09b9b87bfeb870 |
| 11:02 |
Bmagic |
1416 |
| 11:02 |
berick |
csharp_++ Bmagic++ |
| 11:02 |
Bmagic |
csharp_++ |
| 11:04 |
berick |
oh my that's a beast |
| 11:04 |
* berick |
reads about the bug |
| 11:07 |
berick |
csharp_: are yo using the updated MARC editor? |
| 11:07 |
berick |
heh |
| 11:39 |
|
Christineb joined #evergreen |
| 11:54 |
Bmagic |
here's what I came up with: https://gist.github.com/bmagic007/43f3c5ad37aeec1ae642dea0f3ef0c83 |
| 11:54 |
|
jihpringle joined #evergreen |
| 11:55 |
Bmagic |
It's pretty straightforward: truncate coded_value_map (which cascades to composite_attr_entry_definition ) - then re-populate those two tables with stock Evergreen 3.13 from 950.seed. I was encountering an search issue having to do with searching by pubdate, and after running this script, the issue went away |
| 11:56 |
Bmagic |
for reference, this query showed the bug: /eg/opac/results?bool=and&qtype=keyword&contains=contains&query=&bool=and&qtype=title&contains=contains&query=quiet+wilderness&bool=and&qtype=author&contains=contains&query=&_adv=1&detail_record_view=0&locg=1&pubdate=is&date1=2011&date2=&sort=poprel |
| 11:57 |
Bmagic |
the enhanced marc editor also functions fine |
| 11:57 |
Bmagic |
remember: the bug affects only databases that undergo the upgrade* to 3.13. Databases that start life at 3.13 and above are not affected by this bug |
| 12:03 |
jeffdavis |
That doesn't re-insert any of the stuff from update 1416, does it? |
| 12:05 |
Bmagic |
The 1416 upgrade script was generated by a python script. But it was different than what was generated for the 950 seed data. And the seed data seemed OK, whereas the upgrade block wasn't. So, I'm not sure how to answer that. Yes, it inserts the data that makes the enhanced marc editor happy, but (hopefully) not the bad stuff that ended up in the upgrade script |
| 12:06 |
jeffdavis |
Let me rephrase. |
| 12:07 |
jeffdavis |
IMO the next point releases for 3.13+ should include a fix that omits 1416 from the 3.12.3-3.13.0 version upgrade script altogether. |
| 12:07 |
jeffdavis |
For folks who have already run that upgrade script, it seems like your script will leave them with more or less the same data in ccvm etc as if they had omitted 1416 during their upgrade. |
| 12:07 |
jeffdavis |
Does that sound correct? |
| 12:08 |
Bmagic |
It should leave them with the data in ccvm as if they had installed Evergreen fresh at 3.13 instead of upgrading to 3.13 |
| 12:10 |
Bmagic |
the code that was merged to main, both included huge changes to 950 seed data as well as the supplementary upgrade script (1416) |
| 12:14 |
Bmagic |
jeffdavis: well, looking at git now, my assumption is off a little. The commit a9c8faf996fc2d0fc12ba1cdf4d492d38be51b6b didn't change the 950 seed file, but rather 961.data.marc21-tag-tables.sql, so it would seem the ccvm row state shouldn't have received any changes? I'm confused now. |
| 12:16 |
Bmagic |
In other words: why would the patch mess with ccvm only for upgrading databases, and not for new databases? |
| 12:18 |
jeffdavis |
I think Llewellyn found that 961.data.marc21-tag-tables.sql wasn't included in sql_file_manifest, so none of the stuff that 1416 is supposed to do actually exists in a clean 3.13+ install either (I haven't verified this though). |
| 12:18 |
Bmagic |
I see, the 961 file does* mess with ccvm. Using a function. So, I think my patch SQL script needs to run through that code too |
| 12:19 |
Bmagic |
maybe I misunderstand. The 961 SQL code didn't get run upon new installs of Evergreen due to a bug for including it during DB seed? |
| 12:20 |
jeffdavis |
Yes, that's the theory. |
| 12:20 |
Bmagic |
well, in that case, I don't* want to execute the stuff in 961 :) |
| 12:21 |
|
collum joined #evergreen |
| 12:28 |
jeffdavis |
So my proposal would be: (1) Remove 1416 from the version upgrade script (and maybe delete 961 too for good measure?). (2) Advise people who have already upgraded to use your fix_coded_value_map.sql script; it won't restore any local customizations they previously had in ccvm, but it will restore parity with stock 3.13+. |
| 12:28 |
jeffdavis |
(3) Redo whatever 1416 was trying to do so it does it properly (this can happen later IMO). |
| 12:29 |
Bmagic |
totally, however, I'm concerned that we're throwing away what was (probably) needed for the patch to achive it's goals. We need to have a better understanding of what the 961 script was trying to do.... yeah, what you said |
| 12:33 |
jeffdavis |
Bmagic: you might want to run 960.data.marc21-tag-tables.sql after truncating ccvm as part of your fix too (960, not 961) - looks like it adds stuff to ccvm during a fresh install |
| 12:33 |
Bmagic |
ok, I'll update |
| 12:47 |
Bmagic |
weird, the total number of rows that stock rows in ccvm exceeds the SETVAL of 10k now. So, out of the box, the staff client can't create new rows in that table until someone had attempted it over 2000 times to increment the sequence higher than the max ID number |
| 12:54 |
Bmagic |
I'm wrong again, nevermind |
| 12:58 |
Bmagic |
OK, I think I got it, same gist |
| 12:59 |
|
_collum joined #evergreen |
| 13:31 |
csharp_ |
berick: yes, we're using the newer MARC editor |
| 13:37 |
berick |
csharp_: i'm guessing the changes from 1416 were nice-to-have's and not required? |
| 13:37 |
berick |
for basic functionality |
| 14:09 |
|
mmorgan joined #evergreen |
| 14:31 |
Bmagic |
berick: the way I understand it: it's for filling out the field/subfield dropdown menu with accurate LoC information |
| 14:32 |
berick |
Bmagic: k, that's about what I was expecting |
| 14:33 |
csharp_ |
berick: I guess so, since we haven't heard complaints after a week and a half |
| 14:33 |
Bmagic |
:) |
| 14:34 |
berick |
that's what I was looking for, thanks csharp_ |
| 14:34 |
csharp_ |
happy to help! |
| 14:34 |
Bmagic |
csharp_: they've not seen it any other way, but I wonder if you would get some tickets if they were used to the enhanced editor having all of that stuff, and then gone |
| 14:35 |
berick |
presumably those extra bits have never been there for pines |
| 14:36 |
Bmagic |
one thing is pretty certain: 1416 has a bunch of unintended consequences in the advanced OPAC search mainly |
| 14:39 |
|
jihpringle joined #evergreen |
| 15:22 |
|
mantis left #evergreen |
| 15:42 |
|
jihpringle joined #evergreen |
| 15:42 |
Bmagic |
does the git server block IP's? I've been thwarted a few times trying to clone a repo, and I've been coming from an IP that starts with 3.87 |
| 16:23 |
|
mmorgan1 joined #evergreen |
| 16:59 |
|
mmorgan1 left #evergreen |
| 18:22 |
|
jihpringle joined #evergreen |
| 22:18 |
|
sandbergja joined #evergreen |
