| Time |
Nick |
Message |
| 02:07 |
|
Jaysal joined #evergreen |
| 02:07 |
|
scottangel joined #evergreen |
| 08:02 |
|
redavis joined #evergreen |
| 08:03 |
|
cbrown joined #evergreen |
| 08:08 |
|
BDorsey joined #evergreen |
| 08:08 |
|
ianskelskey joined #evergreen |
| 08:40 |
|
kworstell-isl joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:59 |
|
Dyrcona joined #evergreen |
| 09:28 |
|
dguarrac joined #evergreen |
| 09:41 |
pinesol |
News from commits: LP#2049934: Remove trailing TCN spaces from incoming bib records. <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=eaf3c7d2a1c70685ab48779f1c8924ace61d3008> |
| 09:48 |
Bmagic |
redavis: should that patch go back to 3.12? |
| 09:48 |
redavis |
Yes, if possible |
| 09:49 |
Bmagic |
I thought so, but it's not targeted that way |
| 09:58 |
redavis |
Bmagic++ |
| 10:16 |
berick |
anyone aware of an issue where a bib rec fails to ingest at create time (no metabib.* data), but ingests fine after editing the record (regardless of what's edited)? |
| 10:19 |
Bmagic |
berick: not aware of that issue. I'm wondering if this example issue is where queued ingest is on or off |
| 10:20 |
|
kworstell_isl joined #evergreen |
| 10:20 |
|
cbrown_ joined #evergreen |
| 10:20 |
berick |
this is stock. pretty sure it's off. |
| 10:20 |
berick |
only settings enabled are: |
| 10:20 |
berick |
ingest.queued.biblio.insert.marc_edit_inline | | t |
| 10:20 |
berick |
ingest.queued.biblio.update.marc_edit_inline | | t |
| 10:20 |
berick |
ingest.queued.max_threads | 20 | t |
| 10:21 |
berick |
it's not all records, btw, just some. |
| 10:21 |
Bmagic |
perhaps queued ingest is on, and the record came into the database outside of the staff client, it would require the queued ingest tool to be running |
| 10:21 |
Bmagic |
any rows in action.ingest_queue_entry ? |
| 10:22 |
berick |
nope |
| 10:22 |
Bmagic |
dang |
| 10:22 |
Bmagic |
how is the record being created? vandelay? |
| 10:24 |
berick |
yeah marc batch import/export |
| 10:25 |
Bmagic |
welp, we're probably looking at trigger OOP stuff. If you're saying most* of the records are ingested but not all of them, then we can only assume that the trigger mechanism in PG is skipping some, somehow* |
| 10:26 |
Bmagic |
it'll probably require some trial and error. If you have an example record, then maybe take that record as your example and see if it will ingest it when inserted alone. Then start adding more records to the batch until PG skips it, and maybe that will help dial in on the issue? |
| 10:27 |
|
kworstell_isl_ joined #evergreen |
| 10:27 |
Bmagic |
try feeding Evergreen the same marc file via marc stream importer and see if the results are the same. Maybe it's vandelay code and not DB code |
| 10:28 |
berick |
i have a sample that reliably fails. just making sure it's not a known issue before I roll up my sql sleeves |
| 10:28 |
berick |
seems like it would have to be the db since it's triggers, but i'll try some stuff |
| 10:28 |
Bmagic |
it's not something I've ran into, but that doesn't mean it's not a known issue |
| 10:31 |
berick |
fwiw https://valkey01.demo.kclseg.org/marc-no-create-ingest.USMARC |
| 10:32 |
Bmagic |
oh boy, I can probably see why |
| 10:32 |
berick |
this record has other issues.. on kcls/3.11 it ingests OK after a post-create save, on EG main it ingests with funky chars -- like a double encoding -- after a post-create save |
| 10:32 |
Bmagic |
yeah, I'm looking at it |
| 10:32 |
berick |
yeah it's a doozy |
| 10:33 |
Bmagic |
I'm starting to blame the record |
| 10:33 |
berick |
i mean, yeah, it's atypical, but we have quite a few such vendor records |
| 10:33 |
Bmagic |
why did early humans have to migrate around the world and develop completely different character sets. Didn't they know we were going to invent computers |
| 10:34 |
berick |
they were too busy trying to figure out what time it was |
| 10:34 |
Bmagic |
lol, I bet |
| 10:37 |
|
kworstell_isl joined #evergreen |
| 10:38 |
Bmagic |
I wish you luck berick |
| 10:38 |
Bmagic |
It'd be interesting to see if this reveals an Evergreen bug |
| 10:40 |
berick |
thanks. i'll report back |
| 10:41 |
pinesol |
News from commits: LP2084166 MARC edit keyboard fix: up, down, CTRL-D <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=10d5eb8c3b733d5978329089fb3386564a687d8d> |
| 10:49 |
redavis |
mmorgan++ |
| 10:49 |
redavis |
bmagic++ |
| 10:50 |
csharp_ |
early_catalogers_inventing_marc-- |
| 10:50 |
redavis |
I mean, MARC wasn't really meant for what we use it for now. They were just trying to bring order out of chaos. |
| 10:51 |
csharp_ |
<werner_herzog>"Here we see the primeval soup that begat MARC. Observe how the early catalogers scratched MARC tags onto this cave walls"</werner_herzog> |
| 10:51 |
|
redavis_reloaded joined #evergreen |
| 10:52 |
redavis_reloaded |
That's funny. I mention chaos and get a connection rest. |
| 10:52 |
redavis_reloaded |
reset |
| 10:52 |
redavis_reloaded |
chef's kiss to the universe |
| 10:52 |
|
redavis_reloaded joined #evergreen |
| 10:54 |
|
redavis_reloaded joined #evergreen |
| 10:54 |
redavis_reloaded |
Huh. Well, okie. Coffee is apparently needed. |
| 11:01 |
Bmagic |
might try pouring some onto your ethernet cable. Couldn't make it worse :) |
| 11:05 |
berick |
caf-5 |
| 11:05 |
jmurray-isl |
Human PoE...? |
| 11:08 |
Bmagic |
berick++ jmurray-isl++ # hahaha |
| 11:08 |
Bmagic |
if you look under the cable and find a bunch of packets, that's where they went! |
| 11:16 |
redavis_reloaded |
lol, it ain't MY ethernet. And, I just needed an excuse for coffee. |
| 11:17 |
redavis_reloaded |
(and grind some nutmeg for apple butter and experiment with frothing half and half and all the things people with lowkey ADHD do when they just want a cup of coffee) |
| 11:58 |
csharp_ |
redavis_reloaded: frothing half and half has only resulted in warm half and half + tears of frustration |
| 11:59 |
redavis_reloaded |
lol, csharp_, it turned out pretty lovely for me. But my expectations are always pretty low. I was mostly sad that I picked a too_small mug and so couldn't use all of the "milk." |
| 12:00 |
berick |
note to self: ingests can fail with PG WARNINGs instead of ERRs. i was not searching the logs effectively. |
| 12:03 |
|
mantis joined #evergreen |
| 12:04 |
csharp_ |
@blame THE LOGS |
| 12:04 |
pinesol |
csharp_: THE LOGS is really just another name for autogen |
| 12:04 |
* Dyrcona |
wonders if OpenSRF/Evergreen will survive a do-release-upgrade. |
| 12:05 |
csharp_ |
@eightball will it? |
| 12:05 |
pinesol |
csharp_: _I_ don't know. |
| 12:05 |
berick |
ok found the issue. a 1024 character string in (for example) Chinese can still exceed the max btree byte count of 2704 |
| 12:06 |
Dyrcona |
Yeahp. |
| 12:06 |
Dyrcona |
So, sounds like we need to truncate at 1024 bytes, not characters in the indexes. |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:07 |
redavis_reloaded |
Dyrcona +1 |
| 12:07 |
berick |
or at around 675 chars |
| 12:08 |
Dyrcona |
Well.. we're looking at UTF-8 so that might work....256 would be the safest if everything is 4bytes. |
| 12:11 |
Dyrcona |
Oh... I misunderstood the issue slightly.... 675 should be just fine. |
| 12:11 |
Dyrcona |
I was thinking 1024 was the limit but it's 2704.... I wonder if that changes in later Pg releases? |
| 12:12 |
berick |
maybe. it's saying btree version 4 for me (on pg 14) |
| 12:12 |
|
collum joined #evergreen |
| 12:15 |
Dyrcona |
The Pg 17 documentation says "approximately one third of a page (after TOAST compression, if applicable)." |
| 12:15 |
|
collum joined #evergreen |
| 12:16 |
Dyrcona |
So, 1/3 of 8k ~ 2700. |
| 12:17 |
* Dyrcona |
performs do-release-upgrade on a remote VM host server. |
| 12:18 |
Dyrcona |
https://www.postgresql.org/docs/current/btree.html#:~:text=Any%20data%20type%20that%20can,TOAST%20compression%2C%20if%20applicable). |
| 12:20 |
berick |
confirmed changing metabib.metabib_full_rec_value_idx and metabib_full_rec_value_tpo_index to 512 (instead of 1024) fixes the issue. |
| 12:21 |
* berick |
will open an LP |
| 12:22 |
|
collum joined #evergreen |
| 12:26 |
Bmagic |
berick: I'm getting segfaults on my redis utility server when processing action triggers (sometimes). Probably a throughput thing? opensrf_router[1369734]: segfault at 585face15... - and the whole OpenSRF stack is dead, needs restarted. |
| 12:28 |
berick |
Bmagic: hm, hard to guess. |
| 12:28 |
Bmagic |
redis is complaining about overcommit_memory is set to 0 when it starts |
| 12:28 |
|
collum joined #evergreen |
| 12:30 |
berick |
Bmagic: setting aside the router issue for a sec, did you disable persistence in redis.conf via the 'save' config option? |
| 12:31 |
Bmagic |
save "" |
| 12:31 |
berick |
not that it's 100% required, but i'm just not used to seeing that redis message, and it seems to be related to saving |
| 12:31 |
* berick |
nods |
| 12:31 |
Bmagic |
that's the config when it broke |
| 12:31 |
berick |
is the VM running out of memory? |
| 12:31 |
Bmagic |
I think the VM could be running out of memory |
| 12:32 |
Bmagic |
but dmesg -H is "Segfault" not "OOM killer" |
| 12:32 |
Bmagic |
if it were OOM killer, then it would be more clear |
| 12:33 |
berick |
yeah. |
| 12:33 |
Bmagic |
the thing is: on ejabberd, the exact same crontab, it was stable. Maybe redis is just more memory hungry? |
| 12:33 |
berick |
just to be sure, are you running patch c843a8fc ? |
| 12:33 |
Bmagic |
Running main |
| 12:33 |
berick |
redis is not more memory hungry in my experience, just the opposite |
| 12:34 |
Bmagic |
pretty sure that commit is on main. This server is installed with OpenSRF main as of 2 days ago |
| 12:34 |
berick |
in any event, it there's no OOM, it's seemingly more likely just a router issue |
| 12:34 |
berick |
yeah, main has the patch |
| 12:34 |
Dyrcona |
Segfault usually means an attempt to access invalid memory, not running out of memory, like dereferencing a null pointer. |
| 12:35 |
Bmagic |
I was able to make it happen by running a particular granularity action trigger, on a machine that I setup special to just run that one thing |
| 12:35 |
Dyrcona |
It could be caused by a failure to allocate memory, but a use after free is more liekly. |
| 12:36 |
Bmagic |
total used free shared buff/cache available |
| 12:36 |
Bmagic |
Mem: 31Gi 11Gi 1.2Gi 5.0Mi 18Gi 19Gi |
| 12:36 |
Bmagic |
I think it's memory |
| 12:36 |
Bmagic |
gonna give it some swap and try again |
| 12:37 |
Dyrcona |
I doubt it's memory. You've got plenty free. |
| 12:37 |
Dyrcona |
Could be bad RAM... |
| 12:37 |
berick |
debugging segfaults is a bear... raising router log level could help narrow it down some though |
| 12:37 |
Bmagic |
it might have ran out during the run, and settled back down after the stack died |
| 12:38 |
berick |
yeah, kick it off again and watch |
| 12:38 |
Bmagic |
what's the best way to "watch" |
| 12:38 |
berick |
i just meant watch the ram usage |
| 12:38 |
Bmagic |
I understand, but I'm wondering what the best way is to watch it? just top? |
| 12:38 |
berick |
in any event... it should not be using more ram unless there's an undiagnosed leak in the new code |
| 12:39 |
Dyrcona |
Bmagic: ` top -c` in another console window full screen. sort by ram usage. |
| 12:39 |
berick |
yeah, tops fine |
| 12:39 |
Bmagic |
top -c, got it |
| 12:40 |
Bmagic |
I have other utility servers on redis, stable for months |
| 12:41 |
Bmagic |
I think this one just has an exceptional crontab |
| 12:41 |
Dyrcona |
Redis seems much more stable than ejabberd in my experience. That said, I've not tried the latest code. There might be a bug somewhere. |
| 12:42 |
* Dyrcona |
waits for the upgraded machine to finish rebooting. |
| 12:42 |
berick |
Bmagic: anything unusual about this A/T event? more data than most? |
| 12:42 |
Bmagic |
yeah, I think it has a sizable chunk today |
| 12:43 |
Dyrcona |
Autorenewals? |
| 12:44 |
Bmagic |
no, standard template processing, for print notices |
| 12:45 |
Bmagic |
I just ran a query to reset, and there's only 1800 events to process. Imma kick it off and see |
| 12:46 |
Dyrcona |
1800 doesn't sound like that many, unless they're all for 1 user. |
| 12:46 |
Dyrcona |
Sometimes staff have these accounts for special purposes and they end up with hundreds of overdue items all due at the same time. |
| 12:48 |
Bmagic |
2090.7 free going down |
| 12:48 |
berick |
which process(es) are eating the ram? |
| 12:49 |
Bmagic |
OpenSRF Drone |
| 12:49 |
Bmagic |
redis-server |
| 12:49 |
Bmagic |
ok, well, it finished this time |
| 12:50 |
Dyrcona |
Ejabberd would kick the message out if hit the limit. |
| 12:50 |
Bmagic |
though, I'd like to mention that after the action trigger process finished, and I got the prompt back, the memory free didn't go back up... |
| 12:51 |
Bmagic |
I think I'm going to add swap to the machine, and continue to monitor it |
| 12:52 |
Dyrcona |
The drone is probably hanging on to the data. I assume it's a Perl drone? |
| 12:53 |
Bmagic |
gotta run for now, bbl |
| 12:53 |
berick |
gotta run too for a bit, but keeping an eye out |
| 12:58 |
* Dyrcona |
tries do-release-upgrade on an Evergreen vm rather than just build a new one. |
| 13:05 |
Dyrcona |
This VM that I'm upgrading is set up with Redis. I'll switch to OpenSRF main and reinstall after the upgrade. See if I notice anything. |
| 13:10 |
|
cbrown joined #evergreen |
| 14:11 |
Bmagic |
Dyrcona++ |
| 14:12 |
pinesol |
News from commits: LP2046000: Check for staging dupes and alerts <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=a2fc090ab991993aef215c4577773df53b4dc1c1> |
| 14:35 |
Bmagic |
I added 8gb swap, reset the events and running 8k events now. Free memory is 619, swappiness is at it's default 60, and the kernel hasn't decided to use the swap yet. But the process hasn't died either |
| 14:37 |
Bmagic |
it completed all 8k without using swap. Oh well, time will tell. Maybe the kernel gets more confident when it knows there is swap available, and will let processes use as much as it wants |
| 14:38 |
redavis_reloaded |
terranm++ |
| 14:42 |
pinesol |
News from commits: LP2052742 Assure ou setting resolves before checking canSave() <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=2b5b7dba91e1152ef849d4b63fbc600e89651ced> |
| 14:42 |
pinesol |
News from commits: LP2045989: Call Number Templates save only changed fields <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ba05b0b5a1b0631290e8db2bb3428662c1131ed8> |
| 14:51 |
|
redavis joined #evergreen |
| 15:12 |
pinesol |
News from commits: LP#2069358 - Avoid a type error if grid isn't initialized. <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d2c0b8ef6ed6d668087c099d51986b0f1ebd0133> |
| 15:12 |
Dyrcona |
Do we not have to edit /etc/redis.conf for OpenSRF any more? |
| 15:14 |
Dyrcona |
Guess not. |
| 15:17 |
redavis |
mmorgan++ |
| 15:48 |
Bmagic |
mmorgan++ |
| 15:52 |
|
mantis left #evergreen |
| 15:52 |
Bmagic |
Dyrcona: weird, I still edit redis.conf with that "save" change, as per the Evergreen 3.12 release notes |
| 15:52 |
Bmagic |
I must have missed the memo that it's no longer needed? I think berick just made reference to that, this morning. |
| 15:53 |
berick |
Bmagic: that just changed. editing the file is still fine, though |
| 15:53 |
berick |
just simplifies the install process for new installs |
| 15:53 |
Bmagic |
it's not needed (now)? |
| 15:54 |
berick |
Bmagic: depends on whether the added command is present in your redis-accounts.txt file |
| 15:54 |
berick |
specifically: CONFIG SET save "" |
| 15:54 |
Bmagic |
I'm rolling redis-accounts.txt cloned from redis-accounts.txt.example |
| 15:55 |
Bmagic |
with the password injected during make install |
| 15:56 |
Bmagic |
ok, I see. Looking at a fresh installation of OpenSRF (main) - comes packed with that line CONFIG SET save "" |
| 16:04 |
Dyrcona |
berick++ Bmagic++ |
| 16:04 |
Dyrcona |
I let do-release-upgrade overwrite /etc/redis.conf, so wondered when I didn't see anything in the README about it. |
| 16:06 |
Dyrcona |
After doing do-release-upgrade, I `rm -rf /openils/*` and reinstalled OpenSRF main and my test branch of Evergreen base on 3.14.0. |
| 16:07 |
Dyrcona |
It's working so far. |
| 16:12 |
* Dyrcona |
is also ready for translations and release building tomorrow. |
| 16:13 |
redavis |
Dyrcona++ |
| 16:14 |
redavis |
I don't anticipate there being any more merges unless the issue with joins in the reporter gets resolved in last minutes. |
| 16:14 |
Dyrcona |
It would be nice to have that in, but there's always next month. |
| 16:15 |
redavis |
There is. And I just got an email that makes me assume it might not quite be ready. |
| 16:16 |
Dyrcona |
Oh. There it is. :) |
| 16:18 |
redavis |
Hmm, we'll see. There's much action going on that hasn't made it quite to git yet. |
| 16:19 |
Bmagic |
redavis, Dyrcona: I have feedback from Cardinal that Mike's tree.js patch fixed it for them |
| 16:20 |
redavis |
Bmagic++ |
| 16:20 |
redavis |
Is Llewelyn going to sign off? |
| 16:21 |
Bmagic |
I'll poke him to do so, but I doubt it's going to be in the next few minutes |
| 16:23 |
redavis |
I have a tendency to play a little fast and loose, so am overcorrecting. merge pause is supposed to be at 5 p.m. ET which is obviously flexible if there's a real chance that this can get in there tonight. |
| 16:23 |
Bmagic |
well then, he might beat that time |
| 16:23 |
Bmagic |
he's been poked |
| 16:24 |
abneiman |
noting that there's a small update forthcoming from eeevil as well |
| 16:24 |
redavis |
Not to put it firmly out there, but also to put it firmly out there, if he signs off, are you able to do the commit? |
| 16:24 |
redavis |
abneiman++ |
| 16:24 |
Bmagic |
<-- muah? do the commit? |
| 16:25 |
redavis |
Bmagic, yep. If you can. No pressure if you can't though. |
| 16:25 |
Bmagic |
:) I'd love to |
| 16:25 |
redavis |
Rock on. Thank you. |
| 16:28 |
eeevil |
re the reporter, they last "one more failure" test was not related to the problem at hand, but it's also (as abneiman says) fixed, pending testing. LP may not have sent my email to that effect yet |
| 16:29 |
Dyrcona |
eeevil: I got the email with your comment. I'm Ok with that going in if someone signs off tonight. |
| 16:30 |
redavis |
eeevil, I'm just refreshing for comments anyway :-). I think we're waiting on Llewelyn for the actual ticket. Is there another ticket for the "one more failure"? |
| 16:30 |
redavis |
Oh, eeevil, n/m my question. I see the answer in your comment. |
| 16:30 |
Bmagic |
I was about to say |
| 16:30 |
Dyrcona |
:) |
| 16:31 |
Bmagic |
it seems like we should wait until this tree.js branch receives it's additional commit, and maybe Llewellyn can double check it on his test machine, the same as he did with the first commit |
| 16:33 |
Dyrcona |
My answer is it depends on how long we have to wait. |
| 16:33 |
Dyrcona |
I would like to get started tomorrow morning. |
| 16:34 |
Bmagic |
agreed |
| 16:34 |
Bmagic |
5pm Eastern is 25 minutes away? |
| 16:34 |
Dyrcona |
Yeah. |
| 16:35 |
Dyrcona |
It's 5:00 PM EST is 22:00 UTC. |
| 16:35 |
redavis |
Yep. It is. |
| 16:35 |
abneiman |
I mean. It's not like git turns into a pumpkin precisely at 5pm this evening. IOW, if this can go in /waves hands/ sometime tonight, that will still work with your schedule, yes Drycona? |
| 16:36 |
Bmagic |
redavis got me all excited and I was gunho! But it sure feels like it's putting too much pressure on this one bug. It can wait another release cycle IMO. In the meantime, some of us can just cherry-pick the final commit(s) and get them on production without waiting another 30 days |
| 16:36 |
abneiman |
(and mine, as I was planning to run release notes tomorrow first thing as well) |
| 16:36 |
Dyrcona |
Yeah, I'm ok with that, or even early tomorrow morning. |
| 16:37 |
abneiman |
Dyrcona++ |
| 16:37 |
abneiman |
Bmagic are you and Llewellyn down for that? (final review / merge this evening) |
| 16:37 |
Bmagic |
yes, no problem. Though, I've not heard from him since said poke |
| 16:38 |
redavis |
lol, Bmagic, please don't be swayed by my enthusiasm ever. |
| 16:40 |
eeevil |
sorry, async over here a bit. Bmagic, the followup patch isn't related to tree.ts, just upgrading old templates with "funky" joins. it will be an important improvement for specific cases, but new templates only need the extant patches on that branch (as a critical matter). but, it's also just a 3-line patch that's easy (as easy as report stuff is) to reason about, and I put a comment pointing to the new-template version of the code so we can see how |
| 16:40 |
eeevil |
the upgrade code will now do the same thing that the native-angular version does. |
| 16:40 |
abneiman |
Bmagic++ |
| 16:40 |
abneiman |
redavis++ # we love your enthusiasm |
| 16:41 |
Bmagic |
eeevil++ # roger |
| 16:41 |
abneiman |
eeevil++ # patchin |
| 16:41 |
redavis |
abneiman++ #me too :D, but it's not a good gauge for "moderate expectations" |
| 16:41 |
redavis |
eeevil++ |
| 16:43 |
Bmagic |
eeevil: so it's not going to be on the same LP (and same branch?) |
| 16:43 |
abneiman |
redavis: it's OK that's why I'm here, with my grumpy reality boots, stomping as needed |
| 16:43 |
eeevil |
Bmagic: I'm 100% cool with pushing it to the same branch |
| 16:44 |
eeevil |
because, time is short |
| 16:44 |
Bmagic |
that's fine, it means we'll wait |
| 16:54 |
* Dyrcona |
signs out for the day. |
| 17:01 |
|
mmorgan left #evergreen |
| 17:01 |
eeevil |
Bmagic: ok! looking at the clock, I'm going to suggest that I push a branch with just (what we've been calling) the followup commit -- it's separate, but discovered during tree.ts testing -- and if you get the signoffs you want/need on the current branch, I recommend we proceed with merging that. then, if you also like the cut of the new branch's jib, and feel like pulling that in, I'm comfortable with it going in quickly. if it has to sit, I won't |
| 17:01 |
eeevil |
cry too hard. |
| 17:02 |
Bmagic |
ok then, we have something we can test? |
| 17:03 |
redavis |
Bmagic, I think it's the current branch listed at https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-2087562-dynamic-tree-node-parent-links |
| 17:03 |
Bmagic |
that's what I'm looking at. So, roll with that for now, and we'll catch the rest next cycle, is that right? |
| 17:04 |
eeevil |
to that end, here's the followup commit on a branch by itself: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/fix-virtual-field-link-joins-in-upgraded-templates |
| 17:05 |
Bmagic |
eeevil: thanks! And you're not comfortable with that second branch just yet? |
| 17:05 |
eeevil |
Bmagic: next cycle, or this if it looks sane to you. I'm mainly trying to get it out there for others to test/use asap |
| 17:05 |
eeevil |
oh, /I/ am comfortable, but it's not been tested by not-mike. |
| 17:05 |
Bmagic |
understandable |
| 17:06 |
redavis |
How about this, maybe Llewellyn signs off on the first branch tonight.. but probably not. Even if he doesn't, we can get to testing the second branch and have both ready for next month...and for anyone that wants to apply in the meantime. |
| 17:06 |
Bmagic |
well, like you said, it's three lines. Seems like we should be able to test that with some humans. Sure wish we had some e2e tests to do the job for us |
| 17:07 |
* eeevil |
imagines the selenium script that would drive the reporter to test this ... shudders, passes out |
| 17:07 |
redavis |
LOL!!! |
| 17:08 |
Bmagic |
yeah, it'd be one heck of a test |
| 17:09 |
eeevil |
the test is ... clone a report that uses a might_have link on a virtual idl field and make sure it uses the left-side pkey column instead of the virtual column name in the join |
| 17:09 |
abneiman |
I'd be delighted to have the first one go in this evening, for point releases this month |
| 17:09 |
Bmagic |
it's radio silience over there at Cardinal. Maybe they'll get back with me before the "morning" |
| 17:10 |
abneiman |
but! I've put my finger(s) on the scale(s) too many times on this particular issue so with that imma head out and go swimmin |
| 17:12 |
Bmagic |
Llewellyn signed off on the first branch just now |
| 17:12 |
Bmagic |
abneiman must be in the Southern hemisphere |
| 17:13 |
redavis |
lol, or close to the Y |
| 17:13 |
redavis |
also, rock on for the first branch. So, unless anyone wants to stop me (please stop me), I'm going to open a new LP ticket for the second branch to make sure it doesn't get neglected. |
| 17:15 |
eeevil |
redavis: this is me, not stopping you! :) |
| 17:15 |
Bmagic |
yeah, that's a sane course of action I think. Considering the test is nuanced |
| 17:15 |
eeevil |
redavis++ |
| 17:15 |
redavis |
Excellent! This is also you not smellin' a burning clutch. |
| 17:15 |
Bmagic |
digging up an old template that " uses a might_have link on a virtual idl field and make sure it uses the left-side pkey column instead of the virtual column name in the join" |
| 17:19 |
Bmagic |
redavis: pushed! eeevil++ |
| 17:20 |
redavis |
Bmagic++ eeevil++ |
| 17:20 |
redavis |
As they say, "Bam!" |
| 17:22 |
eeevil |
I hope that's a futurama reference. and if not, it is now, in my head. |
| 17:22 |
eeevil |
and with that, I'm running away |
| 17:22 |
redavis |
LOL |
| 17:22 |
redavis |
Have a good night |
| 17:22 |
Bmagic |
you too |
| 17:22 |
redavis |
It was a Bobby Flay reference, I think. |
| 17:22 |
* redavis |
doesn't have authority control |
| 17:23 |
berick |
emeril lagasse by way of futurama |
| 17:23 |
redavis |
Ohhhhh, that's it. |
| 17:23 |
redavis |
berick++ |
| 17:23 |
* redavis |
DOES have authority control |
| 17:24 |
berick |
i got your $0's |
| 17:26 |
redavis |
Yeah you do. Thanks. Okay, LP ticket for cloning and upgrading templates with virtual fields incoming. |
| 17:32 |
redavis |
https://bugs.launchpad.net/evergreen/+bug/2089066 quick and dirty for the LP |
| 17:32 |
pinesol |
Launchpad bug 2089066 in Evergreen "Cloning and upgrading templates with virtual fields in the join tree requires inspecting the reltype" [Undecided,Confirmed] |
| 17:33 |
redavis |
alright friendly friends, imma head out. Thanks for everything from the commits to the lolz. Have a good evening. |
| 17:34 |
berick |
@later tell redavis "friendly friends" is what we call the dogs |
| 17:34 |
pinesol |
berick: The operation succeeded. |
| 17:42 |
pinesol |
News from commits: LP#2087562: Fix node-parent tracking in dynamic trees <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9cfa8e0f3fbaa94c4d07c7b5c5db2cc38336ed2c> |
| 19:05 |
|
jihpringle2 joined #evergreen |
