Change SDR Graveyard in contentable concern

[blalbrit]

https://github.com/sul-dlss/dor-services/blob/master/lib/dor/models/concerns/contentable.rb#L216 references the wrong APO druid - should be: druid:kg712km1576

[jmartin-sul]

clarification question: is there anything behaving as if the graveyard APO druid is the one listed in the comment? the comment doesn't match the desired druid, which it seems like we should fix. but digging into the code a bit, it actually appears to look up the APO by title:

https://github.com/sul-dlss/dor-services/blob/7e1e5fa707e312cbad833f5166ac565a69a32134/lib/dor/models/concerns/contentable.rb#L216-L218

https://github.com/sul-dlss/dor-services/blob/5238883ebede505d7939d11f7fa4c9a4b5dc849c/lib/dor/services/search_service.rb#L83-L94

and that title lookup seems to find druid:kg712km1576 (https://argo.stanford.edu/view/druid:kg712km1576, and running that query directly on the solr admin web UI returns that one result)

[blalbrit]

^^ Hi @jmartin-sul - that's a good clarification. When we try to run decommission, it gives the following error: "ArgumentError: Couldn't find ActiveFedora::Base without an ID" . I assumed at first it was looking for the wrong druid (when I saw the note), but now suspect something more complex is going on.

[jmartin-sul]

huh, interesting. did some testing in rails console with the dor-services methods (on argo-stage). TL;DR, it appears we're not using the right approach to get the id from the solr response. i think if we used the string form instead of the symbol form to refer to the field name, it'd work (i.e. change r['response']['docs'].first[:id] to r['response']['docs'].first['id'] in search_service.rb on line 92).

my terminal investigation:

[1] pry(main)> Dor::SearchService.sdr_graveyard_apo_druid
=> nil
[2] pry(main)> Dor::SearchService.find_sdr_graveyard_apo_druid
=> nil
[3] pry(main)> 

...

[1] pry(main)> r = Dor::SearchService.query('dc_title_tesim:"SDR Graveyard"', :fl => 'id')
=> {"responseHeader"=>
  {"zkConnected"=>true,
   "status"=>0,
   "QTime"=>2,
   "params"=>{"q"=>"dc_title_tesim:\"SDR Graveyard\"", "fl"=>"id", "start"=>"0", "wt"=>"json"}},
 "response"=>{"numFound"=>1, "start"=>0, "docs"=>[{"id"=>"druid:kg712km1576"}]},
 "facet_counts"=>
  {"facet_queries"=>{},
   "facet_fields"=>{"active_fedora_model_ssi"=>["Dor::AdminPolicyObject", 1], "object_type_si"=>[]},
   "facet_ranges"=>{},
   "facet_intervals"=>{},
   "facet_heatmaps"=>{}},
 "spellcheck"=>{"suggestions"=>[], "correctlySpelled"=>true}}
[2] pry(main)> 
[3] pry(main)> r['response']
=> {"numFound"=>1, "start"=>0, "docs"=>[{"id"=>"druid:kg712km1576"}]}
[4] pry(main)> r['response']['docs']
=> [{"id"=>"druid:kg712km1576"}]
[5] pry(main)> r['response']['docs'].first
=> {"id"=>"druid:kg712km1576"}
[6] pry(main)> 
[7] pry(main)> r['response']['docs'].first[:id]
=> nil
[8] pry(main)> 
[9] pry(main)> 
[10] pry(main)> r['response']['docs'].first['id']
=> "druid:kg712km1576"

[blalbrit]

Thanks for this analysis @jmartin-sul - that's a great result. Should we keep work on this ticket or open a new one (somewhere appropriate)?

[jmartin-sul]

i vote for opening a new ticket, and we can reference and close this one. in addition to fixing the way the solr response is accessed, we should list fixing the thing you initially found with the incorrect/misleading comment (either by using the right druid or just not referencing one, i'm not sure how helpful that comment was, or whether it might fall out of date again). or the new ticket could just be about the solr response and this ticket could be about the comment (and kept open in that case).