Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I'm not sure if this is a bug or I am just misunderstanding the use. What I have is an apache solr page that lists out news articles. On the right I tried to make a facet block that would allow the news articles to be filtered by year. But the facet block wouldn't appear. I spent ages looking into it and found drupal was setting the GAP value it sent to solr as month but I had set the granularity of the facet to year so it rejected the results and thus no block. Eventually I found the reason for this. When it works out what to set it to when creating the solr request it seems to choose the largest gap between the oldest and newest article. So while I have test data that ranges across 2 years (2012 and 2013) I didn't have a year between the oldest and the newest. This seems wrong to me. If I had these article dates
01 Sept 2012
01 Dec 2012
01 March 2013
01 June 2013
I would expect a yearly granular facet of
2012 (2)
2013 (2)
instead I get nothing because the gap is calculated as a month since largest - smallest is 8 months and the biggest gap under 8 months is 1 month not 1 year as needed.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | minimum-granularity-bug-2159883-6.patch | 3.83 KB | cpliakas |
Comments
Comment #1
cpliakas commentedThe gaps are actually calculated in the implementing module's query type plugin, for example ApacheSolrFacetapiDate::build(), so I would recommend moving this issue to whatever search backend since Facet API likely won't be able to solve this issue.
Comment #2
cpliakas commentedDisregard last comment, the issue could be in the facetapi_get_timestamp_gap() as well.
Comment #3
cpliakas commentedI think I see the issue.
To sum up, you have set the "Granularity" to "Year" in the date facet's settings page, you have content that spans across two years, but the
facetapi_get_timestamp_gap()function returns a gap of a month because the distance between the earliest and latest dat is less than a year. Therefore the facets aren't displaying.Is this correct?
Comment #4
Daemon_Byte commentedYes that's the issue I was having.
Comment #5
cpliakas commentedGreat, thanks for confirming.
I am wondering it this is as simple as making sure the gap is never more granular than the facet's setting in the implementing module's date query type plugin.
As an example, the ApacheSolrFacetapiDate::getDateRange() method is where we would do this in the Apache Solr Search Integration module.
Comment #6
cpliakas commentedUnfortunately it looks like this is a fix that will have to span both Facet API and the implementing modules.
The attached patch is the proposed fix in Facet API. I will link to that patches that must be applied to the implementing modules. I will start with Apache Solr Search since that is the module I tested against.
The patch adds a comparison function for date gaps and modifies the API function to account for the "Granularity" configuration option. If the minimum granularity is "YEAR" but the calculated granularity is "DAY", the API function will return "YEAR" if the Granularity setting is passed to it.
Comment #7
cpliakas commentedCorresponding patch for Apache Solr Search listed below:
#2299037-1: Date facets not displayed when the configured granularity is larger than the calculated granularity
Comment #8
cpliakas commentedI am going to commit the change to Facet API to get it in to the 7.x-1.5 release, we can now track the fixes in the integrating modules individually.
Comment #11
cpliakas commentedMarking as "fixed" since Facet API added the enabling API, however for this to be fixed from the end user's and developer's perspective the implementing modules will have to implement the new API change as well.
Comment #12
cpliakas commentedCorresponding bug report for Search API listed below:
#2305627: Date facets not displayed when the configured granularity is larger than the calculated granularity