[
https://issues.apache.org/jira/browse/SOLR-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-1709.
----------------------------
Resolution: Fixed
bq. Deprecating data faceting in favour of generic range faceting should be
fine...
that ship has sailed, it was already deprecated in 3.1. facet.range supports
everything facet.date supported, with nearly identical query params, and a
slightly different response structure (it's now easier to parse because the
counts are distinct from the meta values)
my point was just that since facet.date has alreayd been deprecated, it made no
sense to add distributed support for it unlesswe also added distributed support
for facet.rang -- but since you already did the work, there's no harm in having
both.
I've committed this to trunk for 4x. as i mentioned before, i'm leary of
backporting to 3x unless SOLR-1729 is also backported. so i'm resolving for
now and we can reopen if/when that happens
Thanks to Peter and David for their perseverance and prodding (and tests!) to
help get this committed.
Committed revision 1095517.
> Distributed Date and Range Faceting
> -----------------------------------
>
> Key: SOLR-1709
> URL: https://issues.apache.org/jira/browse/SOLR-1709
> Project: Solr
> Issue Type: Improvement
> Components: SearchComponents - other
> Affects Versions: 1.4
> Reporter: Peter Sturge
> Assignee: Hoss Man
> Priority: Minor
> Fix For: 4.0
>
> Attachments: FacetComponent.java, FacetComponent.java,
> ResponseBuilder.java, SOLR-1709.patch,
> SOLR-1709_distributed_date_faceting_v3x.patch, solr-1.4.0-solr-1709.patch
>
>
> This patch is for adding support for date facets when using distributed
> searches.
> Date faceting across multiple machines exposes some time-based issues that
> anyone interested in this behaviour should be aware of:
> Any time and/or time-zone differences are not accounted for in the patch
> (i.e. merged date facets are at a time-of-day, not necessarily at a universal
> 'instant-in-time', unless all shards are time-synced to the exact same time).
> The implementation uses the first encountered shard's facet_dates as the
> basis for subsequent shards' data to be merged in.
> This means that if subsequent shards' facet_dates are skewed in relation to
> the first by >1 'gap', these 'earlier' or 'later' facets will not be merged
> in.
> There are several reasons for this:
> * Performance: It's faster to check facet_date lists against a single map's
> data, rather than against each other, particularly if there are many shards
> * If 'earlier' and/or 'later' facet_dates are added in, this will make the
> time range larger than that which was requested
> (e.g. a request for one hour's worth of facets could bring back 2, 3
> or more hours of data)
> This could be dealt with if timezone and skew information was added, and
> the dates were normalized.
> One possibility for adding such support is to [optionally] add 'timezone' and
> 'now' parameters to the 'facet_dates' map. This would tell requesters what
> time and TZ the remote server thinks it is, and so multiple shards' time data
> can be normalized.
> The patch affects 2 files in the Solr core:
> org.apache.solr.handler.component.FacetComponent.java
> org.apache.solr.handler.component.ResponseBuilder.java
> The main changes are in FacetComponent - ResponseBuilder is just to hold the
> completed SimpleOrderedMap until the finishStage.
> One possible enhancement is to perhaps make this an optional parameter, but
> really, if facet.date parameters are specified, it is assumed they are
> desired.
> Comments & suggestions welcome.
> As a favour to ask, if anyone could take my 2 source files and create a PATCH
> file from it, it would be greatly appreciated, as I'm having a bit of trouble
> with svn (don't shoot me, but my environment is a Redmond-based os company).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
