| Time |
Nick |
Message |
| 07:49 |
|
BDorsey joined #evergreen |
| 08:00 |
|
collum joined #evergreen |
| 08:25 |
|
mantis1 joined #evergreen |
| 08:27 |
|
rfrasur joined #evergreen |
| 08:42 |
|
kworstell-isl joined #evergreen |
| 08:45 |
|
mmorgan joined #evergreen |
| 08:48 |
|
mmorgan1 joined #evergreen |
| 09:58 |
|
sleary joined #evergreen |
| 10:03 |
|
Dyrcona joined #evergreen |
| 10:28 |
|
jvwoolf joined #evergreen |
| 10:49 |
Dyrcona |
Don't confuse actor.org_unit with actor.usr when typing your query. You will get very different results. :) |
| 10:50 |
mmorgan |
:) |
| 10:52 |
berick |
you haven't lived until every user in your database has their own org unit |
| 10:52 |
|
Christineb joined #evergreen |
| 10:53 |
mmorgan |
YAOU!!! |
| 10:54 |
rhamby |
"so, this new patch will allow every user to have their own custom circulation policies at their own org unit" |
| 10:55 |
rhamby |
"and we'll let them mint them as NFTs on a blockchain" |
| 11:01 |
berick |
stop reading my dream journal |
| 11:16 |
Dyrcona |
Heh. |
| 11:28 |
|
jihpringle joined #evergreen |
| 11:48 |
abneiman |
...stop reading my nightmare journal |
| 11:57 |
mmorgan |
abneiman++ |
| 12:09 |
|
mmorgan left #evergreen |
| 12:13 |
|
jvwoolf left #evergreen |
| 12:16 |
pinesol |
News from commits: LP19800544 Import all holdings templates <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5eca8123787b3ea1bfcef436f54c20dc9fcbb01b> |
| 12:42 |
|
kworstell-isl joined #evergreen |
| 12:50 |
mantis1 |
for those who use geo prox, where are the coordinates saved in the db? |
| 13:48 |
Dyrcona |
mantis1: Looks like they go in actor.org_address. |
| 13:48 |
Dyrcona |
There are latitude and longitude fields. |
| 13:51 |
|
mmorgan joined #evergreen |
| 14:03 |
mantis1 |
Dyrcona++ |
| 14:22 |
* Dyrcona |
scratches his head.... |
| 14:24 |
Dyrcona |
So, if I have UPC as an identifier field in config.metabib_field, then metabib.identifier_field_entry where field = 20 should look like UPCs, no? |
| 14:24 |
Dyrcona |
It's config.metabib_field id = 20 for clarity. I forgot to mention that. |
| 14:26 |
Dyrcona |
I just did "select * from metabib.identifier_field_entry where field = 20 limit 100;" and the vast majority of them do not look like UPCs. Do I misunderstand something, or do I have a misconfiguration somewhere? |
| 14:31 |
jeff |
can you explain what you mean by "do not look like UPCs"? also, depending on a number of things, you might have a lot of outliers in that LIMIT 100... |
| 14:31 |
Dyrcona |
Yeah, when I do field = 18 they look like ISBNs, and 18 is ISBN. |
| 14:32 |
Dyrcona |
jeff: No problem: 192326039 | 4144895 | 20 | 1. Selected Economic Indicators, 2014-212. Financial Soundness Indicators, 2010-16; ANNEXES; I. Risk Assessment Matrix; II. Report on the Observance of Standards and Codes (ROSCs)-Summary Assessments of BCP; III. Report on the Observance of Standards and Codes (ROSCs)-Summary Assessments of ICP; IV. Report on the Observance of Standards and Codes (ROSCs)-Summary Assessments of C |
| 14:32 |
Dyrcona |
PFMI; V. Previous FSAP Recommendations; VI. Banking Stress Testing Matrix; VII. Corporate Stress Testing Matrix. 1. The FSCFIGURES; 1. The Macro Context; 2. A Bank Dominated Financial Sector; 3. Banking Sector Profile; 4. Bank Business Model Convergence; 5. Bank Measures of Systemic Risk and Spillover Networks; 6. Banks' FX and Liquidity Risks; 7. Banks' Returns, Asset Quality, and Solvency; 8. Corporate Sector Risks and Vul |
| 14:32 |
Dyrcona |
ies; 9. Summary Results of Solvency Stress Tests of Major Banks; 10. Results of the Liquidity Stress Tests of Major Banks; 11. Funding Liquidity-Solvency Feedback in Solvency Stress Tests; 12. Corporate Sector Stress Test Analysis; TABLES. |
| 14:32 |
Dyrcona |
That's definitely NOT a UPC. |
| 14:32 |
jeff |
ah, yes. |
| 14:32 |
Dyrcona |
That's the first result row. I must have a conflicting definition somewhere. |
| 14:32 |
jeff |
does the source record look like it has all that in an 024 or something? |
| 14:33 |
* mmorgan |
ran Dyrcona's query and saw results that mostly look like UPCs, 12 digit numeric codes. |
| 14:33 |
Dyrcona |
I'll check that, but I was told that we had 246s showing up where UPC should be when there is more than 1. |
| 14:33 |
jeff |
if not, then you likely have (or had) something pulling unexpected data into field 20. there have been some database upgrade scripts that resulted in unusually-pinned field definitions. I know we ran into several display fields like that a while back. |
| 14:36 |
Dyrcona |
jeff: Yeah, that must be it. That data comes from a 505, not 024. |
| 14:36 |
Dyrcona |
So, we've got 505 and 246 possibly showing up. |
| 14:37 |
Dyrcona |
I used to know this part of Evergreen better than I do now. |
| 14:38 |
Dyrcona |
jeff++ mmorgan++ |
| 14:39 |
Dyrcona |
This is on a development/test system. I guess I'll double check production, too. Maybe it was something in this upgrade script.... |
| 14:39 |
jeff |
nothing stock references 505, but in mods that's tableOfContents, which is matched by the xpath for the keyword field "toc". |
| 14:40 |
jeff |
also, that specific record is deleted in your live system, which may or may not mean that its being skipped on reingests/etc. |
| 14:40 |
jeff |
s/its/it's/ |
| 14:41 |
Dyrcona |
Yeah, it's from Ebook Central, and it was likely deleted or replaced with a newer record in production. The development database is a couple of weeks behind. We just did some batch loads. |
| 14:42 |
jeff |
neither upc nor toc were metabib field definitions that found had diverged in our environment when I made notes about it a few years ago. |
| 14:43 |
Dyrcona |
OK. |
| 14:43 |
Dyrcona |
I have a similar issue in production. The first one looks like a 246 alternate title or whatever. |
| 14:46 |
Dyrcona |
Yeah, I haven't changed the xpath for the upc metabib field. We've got some other definition that's broken somewhere. |
| 14:46 |
jeff |
looking at notes a bit more, most of what we were dealing with was that entries in config.display_field_map were pointing at what an upgrade script had thought were pinned/fixed config.metabib_field rows, but in our database at that time, those IDs were different from what the upgrade script thought they would be. |
| 14:47 |
Dyrcona |
I recently did a full/pingest that should have replaced everything. |
| 14:50 |
Dyrcona |
I wonder if we might have busted table inheritance or redundant IDs across two tables that need to be unique? |
| 14:52 |
jeff |
I'm not aware of any inheritence in the vicinity of that data. |
| 14:53 |
Dyrcona |
Yeah, me neither..... |
| 14:54 |
Dyrcona |
I wish I could remember how all of this worked without having to dig through ALL of the tables again. |
| 14:54 |
Dyrcona |
Also, wouldn't be nice if it was just one schema, and not 2? |
| 15:06 |
|
sleary joined #evergreen |
| 15:08 |
Dyrcona |
I have no idea what's wrong.... |
| 15:12 |
Dyrcona |
Think I found it... select * from config.metabib_field_virtual_map where real = 20; is linked to keyword. In fact, everything is linked to keyword. |
| 15:20 |
Dyrcona |
I'm guessing that whoever set this up got the real and virtual fields backwards.... |
| 15:20 |
Dyrcona |
Imagonna truncate the table and start a full ingest. |
| 15:21 |
collum |
Dyrcona: I checked our config.metabib_field_virtual_map (real: 20, virtual: 45 which is all keyword). I browse through 3,000 entries in identifier_field_entry. I didn't see anything that did not look like a UPC. |
| 15:23 |
Dyrcona |
Well, IDK.... |
| 15:24 |
collum |
We are on 3.9.1 |
| 15:25 |
Dyrcona |
We're on 3.7.3 and 3.10.0+. |
| 15:25 |
Dyrcona |
I see this on both. |
| 15:29 |
Dyrcona |
config.display_field_map is another option. |
| 15:30 |
Dyrcona |
And, not likely.... :( |
| 15:34 |
Dyrcona |
Seriously, though, it's looking like keyword is being added to UPC somehow. I'm running out of options, just two tables left to check. |
| 15:36 |
Dyrcona |
authority.control_set_bib_field_metabib_field_map was a bust, no metabib_field = 20.... |
| 15:37 |
Dyrcona |
I'm gonna truncate the virtual map, do an ingest, and see what happens.... |
| 15:38 |
Dyrcona |
Well, let me check FKs on metabib.indentifier_field_entry, first... |
| 15:40 |
Dyrcona |
Could disabling maintain_symspell_entries_tgr have done something strange? |
| 15:42 |
mmorgan |
Dyrcona: We have symspell triggers disabled and don't see the upc strangeness. |
| 15:44 |
|
abneiman joined #evergreen |
| 15:44 |
|
jmurray-isl joined #evergreen |
| 15:44 |
|
miker joined #evergreen |
| 15:46 |
Dyrcona |
Welcome back, miker! Maybe you can help with my indexing issue? I've run out of tables to check. |
| 15:48 |
Dyrcona |
I just started a reingest, but I wonder if this could just be old junk, though it was reported that adding a new 246 showed up in the UPC field in the display. |
| 15:48 |
Dyrcona |
Maybe I should have truncated the metabib tables before doing the ingest? |
| 15:50 |
mmorgan |
Dyrcona: I think you're on to something re:truncating the metabib tables. |
| 15:59 |
Dyrcona |
I stopped the ingest and truncated the identifier_field_entry table. |
| 16:00 |
Dyrcona |
Then started it up again, but I'm concerned that adding a new 246 to a record caused it to show up as UPC. At least, that's how it was reported to me. Maybe I misunderstood the email. |
| 16:02 |
Dyrcona |
I wonder if people know what they're talking about? The example record that I'm given was last updated in 2021 according to the dev database. |
| 16:05 |
mmorgan |
Dyrcona: What is your xpath for config.metabib_field.id = 20? |
| 16:06 |
Dyrcona |
I think I pasted it earlier. |
| 16:07 |
Dyrcona |
Guess I didn't. /marc:datafield[@tag='024' and @ind1='1' or @ind1='2' or @ind1='3' or @ind1='4' or @ind1='5' or @ind1='6' or @ind1='7' or @ind1='8']/marc:subfield[@code='a' or @code='z'] |
| 16:09 |
jeff |
that looks... non-stock. |
| 16:10 |
jeff |
and i worry a bit (without refreshing my xpath syntax) about the AND OR OR... without parens. |
| 16:10 |
Dyrcona |
It is non-stock, but it is correct. |
| 16:10 |
Dyrcona |
Well, it could be that.... |
| 16:11 |
Dyrcona |
Maybe it needs parenthesis? I'll check the xpath docs. I want to emphasize that I didn't implement that change. |
| 16:12 |
* mmorgan |
would suspect those OR's |
| 16:12 |
Dyrcona |
Yeah, maybe... I'm going to try it on a different dev system. |
| 16:12 |
Dyrcona |
"It" being parenthesis... |
| 16:14 |
Dyrcona |
mmorgan++ I think you've found the problem. |
| 16:14 |
Dyrcona |
I was looking at that example record again, and it has ind1='3' in the 246. |
| 16:15 |
mmorgan |
jeff++ saw it first :) |
| 16:16 |
Dyrcona |
Yeah, sorry, jeff++ |
| 16:17 |
Dyrcona |
I'll have to look for other similar modifications. |
| 16:23 |
Dyrcona |
collum++ |
| 16:24 |
jeff |
Also worth noting that even if you fix that xpath to be what it "probably" was intended to be, calling that field "upc" may no longer be accurate if you expand it to include essentially everything but the ISRC. :-) |
| 16:26 |
jeff |
5 and 6 aren't even valid ind1 values for 024, according to LoC :-) |
| 16:29 |
Dyrcona |
Yeah, I was just looking at the LoC docs..... |
| 16:33 |
Dyrcona |
I'm going back to the stock definition. |
| 16:37 |
Dyrcona |
And, I should have clocked out 7 minutes ago! |
| 16:37 |
Dyrcona |
I'll catch you all tomorrow! Thanks for the help! |
| 17:12 |
|
mmorgan left #evergreen |
| 17:17 |
pinesol |
News from commits: LP 1999696 - Saving stat cats and values in holdings templates <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=5b7d750cd7f1cb725819499bebd2b7c919de993f> |
