8000 Bug: custom fields fail to display and index when imported from another exhibit · Issue #3199 · projectblacklight/spotlight · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Bug: custom fields fail to display and index when imported from another exhibit #3199

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.

Sign up for GitHub

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

Jump to bottom
Open
corylown opened this issue Oct 16, 2024 · 3 comments
Open

Bug: custom fields fail to display and index when imported from another exhibit #3199

corylown opened this issue Oct 16, 2024 · 3 comments
Labels
bug

Comments

@corylown
Copy link
Contributor

Description

When an exhibit with custom fields is exported and then that exported file is imported to another exhibit all the custom field information is stored in SolrDocumentSidecar and the keys of the hash get transformed from strings (as they're stored in the original exhibit) to symbols (when imported to the new exhibit). Because we're not handling the possibility that these keys could be either strings or symbols, indexing breaks and the custom field metadata does not appear in the new exhibit.

Steps to reproduce

  1. Export an exhibit with custom metadata.
  2. Create a new exhibit and import the exported file to this exhibit.
  3. Observe that indexing fails and the custom metadata value does not appear in the edit form for items with values in that custom field.

Example of the indexing error from the Stanford Exhibits app:

Screenshot 2024-10-16 at 9 56 03 AM

Comparing the sidecar data for an exhibit created by hand via the UI (id: 9) vs. an exhibit with imported custom fields (id: 10):

 #<Spotlight::SolrDocumentSidecar:0x000000010aba5c88
  id: 9,
  exhibit_id: 5,
  public: true,
  data: {"note"=>"this is a note"}, # <======== Here's the custom field
  created_at: "2024-10-16 06:47:11.953453000 -0700",
  updated_at: "2024-10-16 06:47:52.473365000 -0700",
  document_id: "bn910qm3619",
  document_type: "SolrDocument",
  resource_id: 8,
  resource_type: nil,
  index_status:
   {:ok=>true, :timestamp=>Wed, 16 Oct 2024 06:47:12.016384000 PDT -07:00},
  tag_list: nil>,
 #<Spotlight::SolrDocumentSidecar:0x000000010aba5788
  id: 10,
  exhibit_id: 6,
  public: true,
  data: {:note=>"this is a note"}, # <======== Here's the custom field
  created_at: "2024-10-16 06:47:11.953000000 -0700",
  updated_at: "2024-10-16 06:49:05.854385000 -0700",
  document_id: "bn910qm3619",
  document_type: "SolrDocument",
  resource_id: 9,
  resource_type: nil,
  index_status:
   {:ok=>true, :timestamp=>Wed, 16 Oct 2024 06:49:05.849455000 PDT -07:00},
  tag_list: nil>]

Expected behavior

Spotlight should either always store imported hashes with string keys AND/OR it should be able to handle cases where the keys are either strings or symbols. Since it's likely data is stored with both string and symbol keys in production instances we'll probably need to be able to correctly handle either string or symbol keys in custom metadata
@corylown corylown added the bug label Oct 16, 2024
@dnoneill
Copy link
Contributor

I will need a little time to dig, but right now this looks almost the exact same as what I was seeing in: #3197

@dnoneill
Copy link
Contributor
dnoneill commented Oct 17, 2024 •
edited
Loading

@corylown, 91% sure this is solved with #3197

@corylown
Copy link
Contributor Author

Verify if #3197 fixed the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
Spotlight Community Sprint 2025
Status: No status
Milestone
No milestone
Development

No branches or pull requests
2 participants
@corylown @dnoneill
0