Time |
Nick |
Message |
06:04 |
|
kworstell-isl joined #evergreen |
07:10 |
|
kworstell_isl joined #evergreen |
07:31 |
|
BDorsey joined #evergreen |
07:51 |
|
collum joined #evergreen |
08:11 |
|
rfrasur joined #evergreen |
08:41 |
|
mmorgan joined #evergreen |
09:03 |
|
mantis joined #evergreen |
09:04 |
|
mantis left #evergreen |
09:04 |
|
mantis joined #evergreen |
09:21 |
|
Dyrcona joined #evergreen |
09:22 |
|
jvwoolf joined #evergreen |
09:55 |
|
sleary joined #evergreen |
10:07 |
Dyrcona |
snapd-- snaps-- |
10:08 |
berick |
heh was just reading about those yesterday doing some ubuntu upgrades |
10:09 |
Dyrcona |
Well, I have hit a number of bugs on Ubuntu desktop with snaps and removable media. |
10:10 |
Dyrcona |
Most of them permissions issues, and some supposedly easy to fix but not fixed yet. |
10:11 |
Dyrcona |
Bug 1966203 prompted my plaint this morning. |
10:11 |
pinesol |
Launchpad bug 1966203 in snapd "Syslog shows "systemd-udevd[2837]: nvme0n1: Process ... failed with exit code 1." in Ubuntu 22.04" [High,Confirmed] https://launchpad.net/bugs/1966203 - Assigned to Alberto Mardegan (mardy) |
10:12 |
Dyrcona |
I'm seeing it when trying to "Safely Remove" a 5TB NTFS drive plugged in via USB. |
10:13 |
Dyrcona |
I find it interesting who gets the blame for the breaking change. :) |
10:18 |
Dyrcona |
Containers are overrated. |
10:33 |
jeffdavis |
Snap is symptomatic of everything wrong with modern software development, and also those kids need to get off my lawn. |
10:38 |
berick |
jeffdavis: ah but they aren't on your lawn, they're in a container on your lawn. |
10:39 |
jeffdavis |
:) |
10:39 |
berick |
to be fair though.. |
10:39 |
berick |
@love containers |
10:40 |
pinesol |
berick: The operation succeeded. berick loves containers. |
10:40 |
berick |
no comment on snaps -- more to be learned there |
10:47 |
JBoyer |
Anytime I see containers as part of the documented workflow of a software project this goes through my mind: |
10:47 |
JBoyer |
"Is it hard to install or build software?" https://i.kym-cdn.com/entries/icons/original/000/043/701/Just_Walk_Out__You_Can_Leave.jpg |
10:49 |
JBoyer |
I love the notion of something like LXC and using containers as super-light VMs, but popping up a whole fistful of docker / kubernetes / etc. containers to do what should be simple things? Thanks, but no. |
11:12 |
berick |
@band add A Fistful of Dockers |
11:12 |
pinesol |
berick: Band 'A Fistful of Dockers' added to list |
11:13 |
|
kworstell-isl joined #evergreen |
11:17 |
|
Christineb joined #evergreen |
12:11 |
|
Dyrcona joined #evergreen |
12:19 |
|
mmorgan1 joined #evergreen |
12:34 |
|
collum joined #evergreen |
12:53 |
|
jonadab joined #evergreen |
13:07 |
|
collum joined #evergreen |
13:24 |
* Dyrcona |
sings along with Andy Partridge and Collin Moulding: "Ballet for a Rainy Day." |
13:25 |
Dyrcona |
Which segues to "1000 Umbrellas." |
13:26 |
Dyrcona |
berick: I got this when running osrf_control with the redis branch: [auth] WRONGPASS invalid username-password pair, at /usr/share/perl5/Redis.pm line 311. |
13:26 |
Dyrcona |
It was unexpected, so I must have done something that messed with passwords somehow? |
13:33 |
|
sleary joined #evergreen |
13:39 |
berick |
Dyrcona: you have to reset the accounts any time you restart Redis (or the server/vm) |
13:39 |
berick |
we can handle that differently, but so far i've just been running --reset-message-bus any time I restart services |
13:42 |
|
collum joined #evergreen |
13:52 |
Dyrcona |
berick: Thanks I wasn't aware of that. |
13:53 |
berick |
yeah, i need to document that one |
14:01 |
|
collum joined #evergreen |
15:08 |
|
tlittle joined #evergreen |
15:10 |
|
mantis left #evergreen |
15:11 |
tlittle |
Can someone explain the logic of asset.copy_part_map to me? Why do we have that table instead of just having a column on asset.copy that links to biblio.monograph_part? |
15:16 |
* mmorgan |
listens, inquiring minds want to know! |
15:21 |
Dyrcona |
The commit message is not very helpful: bcd6f20b9a5 |
15:22 |
jeff |
tlittle: because at least at the database level, one copy can be assigned to more than one part. |
15:24 |
mmorgan |
I was noticing that, but I don't think it makes sense that an item would ever be mapped to more than one part. |
15:24 |
jeff |
I don't know without doing a lot more digging if that's something that's fully realized throughout the rest of the code and UI, or if it was something that was designed to leave room for future enhancement, or if it started one way and then changed. |
15:25 |
tlittle |
^ what mmorgan said |
15:25 |
tlittle |
Also, can you even give a copy more than one part in the UI? I don't think so, but I've also never tried |
15:26 |
Dyrcona |
I was just looking in a copy of CW MARS data, and we have a few copies mapped to more than 1 part. |
15:27 |
tlittle |
What's the use case for that / how are they being used? |
15:27 |
Dyrcona |
Looks like we have 3 copies mapped to 2 parts each. I didn't check if any are deleted. |
15:28 |
* Dyrcona |
has no idea. I don't use the software. |
15:28 |
mmorgan |
On the other hand, I recall some discussion at some point of that. One library separates a 4 disc set into 2 parts, another separates it into 4 parts. Theoretically, if a patron wants disc one, it could be included in 2 possible "parts" |
15:29 |
tlittle |
True |
15:29 |
mmorgan |
Maybe it was to leave room for future enhancement. |
15:31 |
Dyrcona |
In general, though, when a separate table is used, it is to allow a one to many or many to many mapping. |
15:32 |
tlittle |
Yeah, that makes sense. I just wasn't seeing the use case for mapping many parts to one copy, but I can see mmorgan's point |
15:33 |
mmorgan |
I haven't read through it all, but here's an early discussion: https://georgialibraries.markmail.org/search/?q=parts#query:parts+page:1+mid:qd2t7jqbi6hajqgm+state:results |
15:36 |
JBoyer |
I suspect all current multi-part items were transferred from one record to another at some point given that it isn't possible to assign more than 1 part (at least on purpose) via the UI. Any discussion about alternative uses or intents seems to have never amounted to anything concrete. |
15:36 |
mmorgan |
tlittle: What do you find problematic about the copy_part_map table? Just added complexity? |
15:36 |
Dyrcona |
I just checked the delete flags on the copies and parts: 1 copy is deleted and the two parts are not, 1 copy is deleted and its two parts are also deleted, the last copy is not deleted and neither are the parts. I suppose I could look up the full part information to see if that helps. |
15:38 |
tlittle |
mmorgan Kinda,yeah. Like no need to make a join if you don't have to. I'm trying to create a query to look for bibs that have monograph parts created, but there is a copy on that bib that doesn't have a part assigned. And I'm sure I'll get there eventually, but I anticipated part to be on acp and it wasn't so that threw me |
15:38 |
JBoyer |
Oh, forgot about deleted interactions. I know I've at least once scripted scheduled removal of deleted parts from copies for some reason. |
15:38 |
Dyrcona |
Nifty! The parts have the same label and are on different. I suspect JBoyer may be on to something. |
15:39 |
Dyrcona |
^^are on different bib records. |
15:40 |
Dyrcona |
And one of the bibs is deleted, so there you go. Looks like it isn't intended to be used that way. |
15:42 |
Dyrcona |
tlittle: It is common for a bib to have copies with parts and some without. I won't argue if it is a good idea or not, but it happens, and sometimes it is on purpose. |
15:43 |
mmorgan |
I found seven items in our db that are linked to two parts. All but one of those items are deleted. For the one item that isn't deleted neither linked part is deleted, but in the client, I see no indication that it's linked to more than one. |
15:43 |
Dyrcona |
mmorgan: Is one of the bibs deleted, like in my case? |
15:44 |
Dyrcona |
I suspect there's a bug in merging bibs. There is/or was also likely a bug in deleting copies that doesn't get part maps. |
15:45 |
tlittle |
As far as I understand it, if some items have parts and some don't, the ones that don't aren't considered for holds unless the patron chooses Any/All Part. Is that not correct? |
15:45 |
Dyrcona |
This little convo could have uncovered up to 3 bugs. |
15:45 |
mmorgan |
Dyrcona: Neither bib appears to be deleted. |
15:46 |
Dyrcona |
mmorgan: Ok, there might be 4 bugs here. :) |
15:46 |
mmorgan |
tlittle: That is correct. |
15:46 |
mmorgan |
Ok! May as well get exponential! |
15:47 |
tlittle |
mmorgan Ok good, that's the assumption I was working under! So then yeah, I want to try to find bibs that have some copies with parts and some copies that don't have them, so we can send it to the libs to add their parts |
15:47 |
Dyrcona |
If the copy is not on a call number/volume linked to the bib, then it might not show up in the client when looking at parts. |
15:49 |
* mmorgan |
adds a few joins to a query on that item... |
15:58 |
mmorgan |
Dyrcona: That item is mapped to a part on a different record from it's call number :-/ |
16:00 |
Dyrcona |
So, you consider the schema to be a bug, then we're up to 6 bugs. :) |
16:00 |
tlittle |
Woohoo! |
16:08 |
mmorgan |
tlittle: that query sounds like a challenge, especially this late in the afternoon :) |
16:09 |
tlittle |
It was probably not the wisest 4pm challenge I could have undertaken :D |
16:14 |
rfrasur |
I just read through the whole parts discussion and am now purposefully going to forget all of it. Especially the six bugs part. |
16:18 |
Dyrcona |
:) Most of them are small, like copy delete not deleting part map, and some may have been fixed. |
16:28 |
rfrasur |
Yeah. I just happen to have a spreadsheet open with 80k items requiring parts |
17:05 |
|
mmorgan left #evergreen |
17:29 |
|
sleary joined #evergreen |
18:43 |
|
scottangel joined #evergreen |
22:27 |
|
sleary joined #evergreen |