-
Notifications
You must be signed in to change notification settings - Fork 2
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
CTDA9-287: Highlighting plugin integration #7
Conversation
From `search_api_solr` at 4.2.9 (932c9d419021e10173ddb91352d3581cdcaf8cb1).
... avoiding pluggable dereferencing for the moment.
... it's now being created on a field (provided a field is configured to do it, anyway)! Wow!
From search_api_solr at 4.2.9.
... thought it might be useful to work-around things, but nah, isn't necessary. Also, not a nice way to make it be used?
... apparently, being multivalued isn't an issue for us presently? Might be an issue if/when we get into dereferencing things, instead of packing the hOCR along?
... doesn't seem to do the trick, seeming to be ignored when exporting config? Could try updating search_api_solr, to see if it gets picked up?
... doesn't appear to work, as overrided values are not used when exporting the config set for Solr.
…plugin-integration
It's probably outside the scope of your requirements, but how difficult would it be to get this to work with a multi-file media arrangement? Or one that may not use the Islandora-style media relationships? My guess is one could subclass a couple of these classes since config forms aren't really part of the search api Solr components |
Presently, we're just targeting Islandora (the module is "islandora_hocr" after all), so dealing with other relationships isn't presently an issue. If necessary, configurability could be introduced on the properties to be indexed via As for multi-file, yeah, not on our radar. It brings up too many questions of what nature of HOCR can/will/could/would be generated (an aggregated HOCR of all the pages, or a separate HOCR file for each, then matching on delta?), and introducing unnecessary complexity into the base implementation that could be better handled/isolated in a dedicated module. That said, the handling of such would be more on the property/processor side, to actually get things indexed and making use of the query results. The request handler and field type could probably be used, but not so much the indexing (or querying) bits themselves that are specific to dealing relative to the node. Could see whatever multi-file support as a separate module, potentially? |
Co-authored-by: Jordan Dukart <jordan@discoverygarden.ca>
No description provided.