Skip to content
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

Skip suppressed records when indexing. #53

Draft
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

maccabeelevine
Copy link
Member

@maccabeelevine maccabeelevine commented Feb 7, 2025

The Solr index may contain records that should be suppressed for discovery, i.e. this in searches.ini

[RawHiddenFilters]
0 = "-suppress_from_discovery_boolean:\"true\""

Those records are still present in the browse indexes because they don't use these hidden filter settings. This PR allows a the same boolean Solr field to be used to skip records in the browse index as well.

boolean skipDocument = false;
if (skipField != null) {
String[] skip = doc.getValues(skipField);
skipDocument = Arrays.asList(skip).contains("T");
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is insane to me that the API returns "T" for the boolean true, but so be it.

@maccabeelevine
Copy link
Member Author

I developed this against our production VuFind 9.1, which uses an older version of this vufind-browse-handler, library, so have not tested it as is here. Will hopefully do so late summer (once we upgrade locally) unless someone beats me to it. So leaving as draft for a while.

@demiankatz
Copy link
Member

Thanks, @maccabeelevine! Do you think it might be worth making this a little more flexible, e.g. to allow filtering on more than just Boolean types? At Villanova, we use a string field to index the contents of FOLIO's OAI-generated 999$t, so this logic wouldn't work for us in its current form. It would certainly be possible for us to change our indexing processes to make it work, but I imagine there might be other use cases where filtering on one or more string values could be helpful (e.g. using locations to generate separate browse indexes for different members of a consortium). I'm certainly open to accepting this as-is and generalizing it later, but I wanted to suggest these possibilities in case generalizing it now would be worth the effort. (It would certainly be easier for me to help test if I didn't need to redesign my own local index to do so).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants