The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Apache Solr provides a way to set "facet query" parameters to determine the facet count flexibly. The date_facets module uses these facet queries when using the apachesolr backend (which allows to directly modify the solr query, which is not possible via search api). I need the same functionality, but am using search_api and search_api_solr. So, to support this, there are two options (I think):
1) Create a abstraction for facet queries and properly support this in search api
2) Allow facetapi facets to set options, that may then be used by a search api backend
As I am not sure how useful facet queries are for other backends, and as I am not too familiar with search api, I went for the second way. The attached patch to search_api_facetapi allows facets to set a query_options to the $facet array, which is then merged with the regular facet info that is passed to the search api backend.
See #2128517: Properly determine facet count when using search_api_solr for patches to date_facets and search_api_solr that make use of this feature by using a "facet_query" property to properly support counts on date range facets.
| Comment | File | Size | Author |
|---|---|---|---|
| search_api-facetqueries.patch | 878 bytes | Frando |
Comments
Comment #1
drunken monkeyI don't pretend to understand very much about the inner working of the Facet API (sadly), but I think the
$facetarray is something that is normally stored in and loaded from the database, right? So adding additional options there just for passing them to the adapter is a bit risky, as they might inadvertently be saved along with the facet if some other module later saves the facet. On the other hand, this risk is severely mitigated by the fact that the facet is an array, not an object, so the change should be encapsulated to those two methods (the one in the query type plugin where it is made andaddFacet()where the facet is passed to) anyways.I'd maybe have rather added a third, optional parameter to the
addFacet()method, but it's fine this way, too, I guess.Other than that, the only objection I'd have is that I'd rather use
+thanarray_merge()for combining the two options. It's cosmetic, really, but I usually only usearray_merge()for numeric arrays. We'd have to switch the operands in that case, though, to provide the same overwriting ability (if that's on purpose). You don't need to make the change, though, as long as it's OK for you I can just do that when committing (if I remember, otherwise it's my own fault).That aside, it seems like a nice patch, just adding some additional flexibility. See the Solr module issue for my comments on how you use that.
Comment #2
drunken monkeyOh, forgot to add: if my proposed change is OK for you, I'll just wait a few more days and commit then.
Comment #3
g089h515r806 commentedworks perfect.
Comment #4
drunken monkeyAnd, committed. I even though about my little style change.
Thanks again for your contribution!