Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.To help support the need for non-standard query types (like Search API Attachments' need for an extract query) I propose adding a function to allow creation of getQuery() that's similar to the current getUpdateQuery() and getSelectQuery().
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 2831801-07.search_api_solr.extract_query.patch | 2.07 KB | ekes |
Comments
Comment #2
acrosmanAdding related issues.
Comment #3
mkalkbrennerSolarium distinguish between various query types. I already considered a generic function like getQuery($type).
But it makes more sense to have an explicit call for a required type. I recently added getTermsQuery().
Which query type do you need?
Comment #4
acrosmanThis is my attempt to generalize the issue that was raised for the attachments module. If the generic is problematic is there a reason not to create a function for each query type so they are all exposed?
Comment #5
ekes CreditAttribution: ekes as a volunteer commentedIs there a reason to abstract away Solarium completely?
Could there not just be a method to get $solr and modules requiring to do something special could just operate with the Solarium API with the connection already set?
Comment #6
mkalkbrennerThe problem is that there's not just "one connection". A solr service provider could have different endpoints and different handlers. For example the term query sends a request to the "terms" request handler by default in solarium. A service provider might change this.
Personally I plan to do so for the suggester query because we'll have multiple of them.
And some query types might require additional plugins to successully connect a service provider's installation.
I'm not a fan of abstracting libraries but I think it would be the best to have a dedicated getter for each query type.
If anyone has time for such a patch, please go ahead ;-)
Comment #7
ekes CreditAttribution: ekes as a volunteer commented>> Is there a reason to abstract away Solarium completely?
> A solr service provider could have different endpoints and different handlers... A service provider might change this.
Yes then :-) So adding them one-by-one as needed:-
The createExtract() and extract() presently used by search_api_attachment. I've standardized the name as the same as the rest of SolrConnectorInterface, thus getExtractQuery. But the arguments, and returns, are exactly as they are in Solarium. This works with the search_api_attachment test; not sure if there is an obvious non-trivial test that can be written in search_api_solr module.
Comment #8
ekes CreditAttribution: ekes as a volunteer commentedComment #10
mkalkbrennerIt would be great to have an integration test like we have for facets and search_api_autocomplete. But that could be done in a new issue.
Comment #11
ekes CreditAttribution: ekes as a volunteer commentedDid this as a pull request https://github.com/mkalkbrenner/search_api_solr/pull/12 because it's easier with a binary file now.
Comment #12
J.Campbell CreditAttribution: J.Campbell commentedI've applied this patch to my test environment, it is working correctly so far.
Comment #13
mkalkbrenner@ekes: I merged your pull request and adjusted it. thanks :-)
BTW your patch discovered some general issues with our default configs regarding libs.
Comment #15
simon_h CreditAttribution: simon_h as a volunteer commentedI have installed the latest version of Search API Solr Search with this patch but my files aren't indexed anymore. Previously I had this patch: https://www.drupal.org/files/issues/unexpected-error-after-saving-config..., which worked in my case. I made sure I have the latest version of Search API Attachement and Search API Solr Search. Anybody has a simular issue?
Comment #16
mkalkbrennerAt least you need to apply the latest patch from #2696901: Leverage extraction support of Search API Solr integration, fix incompatibilities for various solr service providers incl. Acquia Search