Time |
Nick |
Message |
07:22 |
|
kworstell-isl joined #evergreen |
07:34 |
|
BDorsey joined #evergreen |
08:06 |
|
redavis joined #evergreen |
08:11 |
|
cbrown-isl joined #evergreen |
08:58 |
|
Dyrcona joined #evergreen |
09:05 |
|
Dyrcona joined #evergreen |
09:11 |
|
dguarrac joined #evergreen |
09:23 |
|
mmorgan joined #evergreen |
09:32 |
|
BDorsey joined #evergreen |
10:22 |
|
mmorgan left #evergreen |
10:32 |
Dyrcona |
Hm.... |
10:35 |
Dyrcona |
I don't suppose it would be possible to do an array_agg and group by on a cstore search_.... |
10:38 |
csharp_ |
@decide dark mode or GOTH MODE |
10:38 |
pinesol |
csharp_: go with dark mode |
10:38 |
csharp_ |
@band add Goth Mode |
10:38 |
pinesol |
csharp_: Band 'Goth Mode' added to list |
10:38 |
csharp_ |
(credit to terranm) |
10:40 |
berick |
@band add Depeche Commode |
10:40 |
pinesol |
berick: Band 'Depeche Commode' added to list |
10:42 |
Dyrcona |
berick++ |
10:42 |
Dyrcona |
Yeah, I don't think what I want to do will work. |
10:42 |
csharp_ |
berick++ |
10:43 |
csharp_ |
reach out and touch me |
10:43 |
Dyrcona |
Your own personal... bidet... |
10:44 |
Dyrcona |
I'm going to try it anyway. Watch it blow up. |
10:48 |
Dyrcona |
Ooh. Even if it adds an aggregate column, it's gonna group by the column that I'm trying to aggregate... Well, let's see. |
10:49 |
|
jvwoolf joined #evergreen |
10:51 |
Dyrcona |
Yeahp. No result... I'll have to group in code. |
10:51 |
Dyrcona |
I can order by, though... that would make it easier. |
11:12 |
Dyrcona |
Wow! Never realized how many EDI accounts have the same host, username, password and directories. |
11:12 |
Dyrcona |
Maybe just a "distinct on" would solve the problem.... |
11:13 |
berick |
Dyrcona: same here. the design could use some refactoring :\ |
11:14 |
Dyrcona |
berick: That's what I'm working on. Lp 1836908 |
11:14 |
pinesol |
Launchpad bug 1836908 in Evergreen 3.11 "EDI File Transfer Needs to be Smarter" [Medium,In progress] https://launchpad.net/bugs/1836908 |
11:14 |
Dyrcona |
I'm trying to just handle it with the Perl, but I'll change the schema if I must. |
11:18 |
Dyrcona |
I think adding a group by on host, username, and password would solve a big chunk of the problem. |
11:18 |
Dyrcona |
None of my accounts have different directories where the rest is the same. |
11:19 |
Dyrcona |
Of course, that might break the query. |
11:21 |
berick |
Dyrcona: i see. yeah i was thinking specifically about the duplication in the DB, but I see the obvious crossover |
11:22 |
Dyrcona |
I'm going to try group_by in the cstore search. I suspect it will blow up with an error because we're fleshing the provider. |
11:22 |
Dyrcona |
Oh, never mind: "A JSON query has no separate construct to define a GROUP BY clause." |
11:36 |
berick |
Dyrcona: maybe just {"select":{"acqedi":["host","username","path","in_dir"]},"from":"acqedi","distinct":1} |
11:37 |
Dyrcona |
berick: Yeah. I'm playing with code I copied from the edi_fetcher.pl. I should see how the rest is being used by RemoteAccount.pm before doing something that drastic. |
11:38 |
* berick |
nods |
12:03 |
|
jihpringle joined #evergreen |
12:03 |
|
Christineb joined #evergreen |
12:13 |
Dyrcona |
This is why I kept putting this off: there are a couple of places this could be fixed, and then there's the temptation to rip it up and implement something quite a bit different.... |
12:21 |
Dyrcona |
I suppose I could build a copy of the provider/account list and use grep to prevent duplicates. |
12:29 |
Dyrcona |
That works in my simple test. The list went from 180 to 29. |
12:47 |
Dyrcona |
heh. I typoed "Depulicate" as "Depuplicate" and my spell check suggested "Depopulate" with also works. :) |
12:48 |
Dyrcona |
OMG!!! "Deduplicate" not "Depulicate.".... |
12:48 |
Dyrcona |
@blame finger |
12:48 |
pinesol |
Dyrcona: finger is why we can never have nice things! |
12:48 |
berick |
@band add The Depopulaters |
12:48 |
pinesol |
berick: Band 'The Depopulaters' added to list |
12:49 |
Dyrcona |
berick: I ended up adding a loop in O::A::Acq::EDI::retreive_core to remove duplicate accounts/in_dir combinations from the list. I can test it in a minute. I'll put a link to the commit once I've pushed it to the working repo. |
12:58 |
|
jvwoolf joined #evergreen |
13:00 |
jeffdavis |
I think "depulication" would technically be flea removal. |
13:09 |
Dyrcona |
jeffdavis++ |
13:10 |
Dyrcona |
berick: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=aed84a28b064fa4d2a472cfe38afda3304dfddea |
13:12 |
|
collum joined #evergreen |
13:24 |
Bmagic |
do any of you index the 035 for OCLC number searching? |
13:46 |
Dyrcona |
Bmagic: I'm looking, but I don't think we do. |
13:46 |
Dyrcona |
Related to my earlier conversation: Looks like the patch works! |
13:48 |
Dyrcona |
Bmagic: We don't but I think you'd want a marc on 035, not sure which subfield. |
13:49 |
Bmagic |
it's $a |
13:49 |
Dyrcona |
That is a marc xpath. |
13:52 |
Bmagic |
yeah, this is what I've got: //marc:datafield[@tag='035']/marc:subfield[@code="a"] |
13:53 |
Dyrcona |
Is it working? field_class = 'identifier'? |
13:53 |
Bmagic |
I'm concerned about the commonly prefixed OCLC numbers "(OCoLC)" - and whether or not the index will allow for us to search by just the bare number |
13:54 |
Bmagic |
I haven't introduced it yet |
13:54 |
Bmagic |
I thought I would see if someone else has done this and perhaps took a different path |
13:54 |
Dyrcona |
What does metabib.identifier_field_entry.index_vector look like? |
13:54 |
Dyrcona |
Oh, I see. |
13:55 |
Bmagic |
DIG meeting time! (on zoom in case you thought I meant in IRC) |
13:55 |
Dyrcona |
My guess is that it will work. index_vector should get split up with ocolc and the number. |
13:58 |
Bmagic |
https://us06web.zoom.us/j/84441505629?pwd=eXF1RFRUVXoyTjVxQjdvQk55WVRhdz09 |
14:13 |
collum |
Bmagic - I think there's a default 35a$. It's labeled System Control Number. |
14:15 |
Dyrcona |
collum++ |
14:15 |
Dyrcona |
We have it. |
14:28 |
Bmagic |
collum: not finding it in the interfrace |
14:30 |
|
smayo joined #evergreen |
14:37 |
|
dguarrac joined #evergreen |
15:32 |
Dyrcona |
Ugh! Typo in a commit message..... Those bug me, particularly my own. |
15:35 |
Dyrcona |
commit 009e48a0a7 |
15:35 |
Dyrcona |
commit 24ff30d79 |
15:35 |
Dyrcona |
commit 24ff30d79dc651432373fcea4317d3a408da7090 |
15:37 |
Dyrcona |
Guess that doesn't work any more, or I'm doing it wrong. :) |
15:43 |
jeff |
depends on the repo. |
15:44 |
jeff |
are those working repo commit hashes? |
15:44 |
jeff |
then pinesol doesn't resolve them, iirc. |
15:47 |
jeff |
it might only do configured branches, also. |
15:47 |
jeff |
commit 51ac6c6 |
15:47 |
jeff |
or, it's broken. whee! |
15:47 |
jeff |
I'll try to take a look later. |
15:56 |
Dyrcona |
It's all right jeff. I could take a look later, too. |
15:57 |
Dyrcona |
Bet it stopped working when we set up the new VM for the repos and/or renamed the branch to main. |
16:05 |
Dyrcona |
commit 24ff30d79dc651432373fcea4317d3a408da7090 |
16:05 |
Dyrcona |
Not that simple, huh. |
16:06 |
Dyrcona |
Um... It doesn't take 4 of us to fix it, does it? :) |
16:06 |
* Dyrcona |
butts out. |
16:08 |
* jeff |
overrides the default branch in the ini and rehashes the git plugin... and waits |
16:12 |
* Dyrcona |
was getting there, but someone else had git.ini open... :) |
16:19 |
berick |
abneiman: sleary: Bmagic: may have found a good one: marc editor -> edit a subfield value -> save changes -> instead of saving the value clears |
16:19 |
berick |
seeing same on my 'main' dev server |
16:19 |
berick |
s/saving /saving, / |
16:21 |
sleary |
nooooooooo |
16:21 |
berick |
hm, also arrow-right within subfield text content makes the cursor jump back to the subfield code |
16:22 |
jeff |
commit 2140674 |
16:22 |
sleary |
hmm, that I can fix. Might need eeevil to look at the subfield values. |
16:23 |
eeevil |
COMBOBOOOOOOXXXXXX!!!!!!!!! |
16:24 |
eeevil |
(actually, sfv probably isn't a combobox issue. that should be a plain input. which only makes it more annoying, really) |
16:25 |
jeff |
git plugin doesn't appear to support on-the-fly change between branches, removing the shallow copy of the repo on disk and rehashing pulls the right branch. still failing with an error in the bot's log. might be a python git library dependency issue. suspending troubleshooting for the moment. |
16:25 |
Dyrcona |
jeff++ |
16:26 |
Dyrcona |
I might take another look after I get home. I'm not sure how much we really need that plugin anyway. |
16:30 |
Bmagic |
berick: abneiman: sleary: https://bugsquash2.mobiusconsortium.org installed from tarball, no prob. Can login, search, etc. |
16:30 |
abneiman |
berick++ Bmagic++ |
16:30 |
abneiman |
combobox-- |
16:30 |
Bmagic |
is that a show stopper? |
16:31 |
abneiman |
the lack of saving a subfield value is, IMO |
16:31 |
abneiman |
the keyboard shortcut less so |
16:31 |
Bmagic |
it's nasty actually |
16:31 |
Bmagic |
completely deleting the value |
16:31 |
abneiman |
yes |
16:32 |
berick |
not really a shortcut, but an inability to move the curser to the character you want to edit |
16:32 |
Bmagic |
WTF, it didn't do that in a previous test |
16:32 |
abneiman |
anyway I think we have a fix |
16:32 |
abneiman |
stand by |
16:34 |
sleary |
I'm seeing the right arrow issue, but I have no problem saving an edited subfield. |
16:35 |
Bmagic |
bugsquash2 reproduces the saving issue berick describes |
16:35 |
berick |
ah was just double checking there |
16:35 |
berick |
confirmed |
16:35 |
berick |
sleary: try one of the multi-line fields |
16:35 |
sleary |
k |
16:36 |
Bmagic |
ah, yes, maybe that's the difference. I, for some reason gravitated towards a "bigger" field, 500a |
16:36 |
berick |
yeah, other fields save OK for me too |
16:36 |
sleary |
... yeah, that's bad |
16:36 |
berick |
Bmagic: same :) |
16:37 |
Bmagic |
interesting. What a nuance. Thinking back to when I tested that branch, I edited marc records like crazy but I don't think I interacted with a larger subfield like that |
16:37 |
abneiman |
I'm not seeing it on our internal 3.13-rc, even in multi line fields |
16:37 |
abneiman |
weird |
16:37 |
Bmagic |
weird indeed. Imma install from git and see |
16:37 |
abneiman |
it = not saving subfield value |
16:38 |
abneiman |
I think ours was upgraded, not clean install, if that's relevant |
16:39 |
Bmagic |
be about 10-20 minutes on that |
16:40 |
Bmagic |
and I have a meeting right now, so afk |
16:41 |
abneiman |
right right, I was mixing up tag with data, so I should step away because I am not helpful. so, confirmed on RC, FWIW. sleary and miker are looking at it. |
17:10 |
|
jvwoolf left #evergreen |
17:11 |
sleary |
berick are you still around? |
17:11 |
|
jihpringle joined #evergreen |
17:15 |
berick |
sleary: yes |
17:19 |
* berick |
sees the working branch |
17:20 |
sleary |
berick I think we have a fix, but eeevil just found a bunch of missing libraries on my dev server that are causing other problems |
17:20 |
sleary |
testing it on a different server now |
17:20 |
eeevil |
deploying to butternut for testing now... |
17:22 |
berick |
seems partly fixed. editing existing values is better. creating new ones is still having issues. |
17:24 |
|
kworstell-isl joined #evergreen |
17:24 |
eeevil |
berick: you mean the arrow key issue, or something else? |
17:26 |
berick |
no, the value disappearing isssue |
17:26 |
berick |
on a new, e.g., 500 a value |
17:26 |
berick |
well, new 500 a field |
17:27 |
berick |
arrow issue persists as well but guessing that's a different thing |
17:27 |
sleary |
yeah, I'm not as worried about the arrow thing at the moment. A new 500 a works for me on butternut |
17:28 |
eeevil |
hrm, I was able to add a new subfield (textarea type) to an existing tag |
17:28 |
sleary |
and I don't see any other instances of innerText lurking in the code |
17:30 |
eeevil |
but a new datafield with a new textarea-type subfield, the subfield value didn't save. trying something else |
17:30 |
berick |
yeah, that |
17:30 |
sleary |
ah, I see it |
17:32 |
eeevil |
berick: I was able to get into the subfield code box with keyboard only, you have to tab to get to the whole subfield group, then arrow once the whole group is selected to get into the subfield code, then tab again between subfield sub,um,fields |
17:34 |
eeevil |
oh, the problem with the fresh datafield version of this is that it wants to grab the element by id during the ngAfterViewInit hook, but it changes the input to a textarea based on the tag, which changes after ViewInit |
17:35 |
sleary |
>.< |
17:35 |
eeevil |
I think we should just use model for the textarea like we do for the <input> small-field version |
17:35 |
sleary |
seems reasonable |
17:35 |
eeevil |
(that's a holdover from when everything was an editable div, not a new idiom, for the room...) |
17:36 |
sleary |
mostly I keep my seething hatred for Angular's handling of element IDs in our internal Slack. |
17:57 |
* berick |
disappears |
19:11 |
|
jihpringle joined #evergreen |
19:36 |
|
jihpringle joined #evergreen |
22:46 |
pinesol |
News from commits: Save multiline contents in MARC subfield values <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=af5c71d6d8b6f0d945ed029ca8fb3e31b13cd22b> |