-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Index mhld_display as a json field #1247
base: main
Are you sure you want to change the base?
Conversation
lib/traject/config/folio_config.rb
Outdated
end | ||
|
||
to_field 'mhld_display_struct' do |record, accumulator, _context| | ||
record.mhld.each { |holding| accumulator << holding.to_h } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're starting something new, do we really want/need to replicate the old structure here, or is it worth mirroring either the FOLIO data structures or how Searchworks actually uses this data?
Back in https://github.com/sul-dlss/searchworks_traject_indexer/pull/876/files, I suggested one possible structure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cbeer I added a second commit to this PR. Is this more like what you have envisioned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it were me (and it was, in #876), I'd go a little further. At the very least, latest
is always the same value for a location, so there's no reason to keep duplicating it for each holdings note.
In #876, you'll see I proposed a data structure that Searchworks should be happy to consume and requires less processing in the indexer:
library:
location:
holdings: []
index: []
supplements: []
latest_received: ''
note: ''
It's not clear to me how the FOLIO model changes that general approach, but:
- I think
note
could be multivalued? - in MARC, the 866, 867, and 868 (e.g. holdings, index, supplements) could be freely interleaved and maybe order was important. In FOLIO, they're separate fields so I feel even better about breaking them apart as above.
Maybe there's other things; I'd encourage you to look at the FOLIO data model, what Searchworks is actually doing this this data, and the backlog of MHLD-adjacent tickets in order to figure out what we should do:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cbeer I'm not seeing where searchworks needs to differentiate between regular holding statements, index holding statements and supplement holding statements. Can you explain more about why you chose to take the data model in that direction?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is essentially FOLIO's data model. We currently differentiate between them here in the indexer:
https://github.com/sul-dlss/searchworks_traject_indexer/blob/main/lib/folio/mhld_builder.rb#L67-L73
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, but Searchworks needs them merged together, so is there any reason not to just have one set?
350c6cd
to
4311df3
Compare
This makes it easier to work with
7ba6489
to
d92ee35
Compare
d92ee35
to
873dd5d
Compare
This makes it easier to work with