Topical Term authority field mapped to incorrect Metabib field

Bug #2011147 reported by Mackenzie Johnson
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
New
Undecided
Unassigned

Bug Description

Evergreen 3.8.0

I'll post the SQL query up top so there's a visual aid to the issue.

select acsaf.tag as auth_tag, acsaf."name", acsaf.id as authority_field, cmf.id as metabib_field, acsbf.tag as bib_tag, cmf.field_class, cmf.label
from authority.control_set_authority_field acsaf
join authority.control_set_bib_field acsbf on acsaf.id = acsbf.authority_field
join authority.control_set_bib_field_metabib_field_map bfmf on acsbf.id = bfmf.bib_field
join config.metabib_field cmf on bfmf.metabib_field = cmf.id;

If you look in the results, you will hopefully notice that authority field for the Topical Term Heading maps to the Geographic Name Browse metabib field, as opposed to the topical term metabib field.

Breaking down the joins, it looks like the change would have to happen for id# 8 in the table authority.control_set_bib_field_metabib_field_map, changing the metabib_field value for that id from 35 to either 34 (which would map it to Topical Term Browse), or 14, which would make the mapping consistent with the rest of the table.

Revision history for this message
Michele Morgan (mmorgan) wrote :

Mackenzie,

I ran your query on two systems, our production system running 3.7.2, and also a master system built on 3/6/23, just after Bug Squashing Week.

On both systems your query returned this row:

auth_tag name authority_field metabib_field bib_tag field_class label
150 Heading -- Topical Term 5 34 650 subject Topic Browse

Could what you're seeing be from a change that was made to your database some time in the past?

Revision history for this message
Mackenzie Johnson (mtjohnsonupei) wrote (last edit ):

It is absolutely possible that that is the case, Michele, and if that proves to be so, then that does make for an easy fix on my end. Is your Master system running 3.7.2 as well? I guess technically that was released after 3.8.0, so if it was a widespread issue in the default database setup, it could have been rectified in between the two releases. And now I'm also wondering how much of an impact version updates have directly on the database (probably a non-zero amount, but it's worth asking).

Good to hear that it's linking to an appropriate field on your end, though!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.