[
https://issues.apache.org/jira/browse/SOLR-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-258:
--------------------------
Attachment: date_facets.patch
First pass, no tests but the basics work ... i'm not all that happy about the
cleanliness of the code yet (particularly the back and forth of format
conversions).
Params...
* facet.date = FIELD_NAME ... multivalued
* (f. FIELD_NAME.)facet.date.start = DATE ... single value, per field
overridable, date that supports "NOW" style date math strings
* (f. FIELD_NAME.)facet.date.end = DATE ... single value, per field
overridable, date that supports "NOW" style date math strings
* (f. FIELD_NAME.)facet.date.gap = DATE_MATH_STR ... single value, per
field overridable, date math string (ie: "+1DAY")
* (f. FIELD_NAME.)facet.date.other = pre | post | inner | all ...
multivalue, per field overridable, string indicating what "other" info we want
about the range:
o pre = the count of matches before the start date
o post = the count of matches after the end date
o inner = the count of all matches between start and end
o all = all of the above (default value)
o none = no additional info requested.
Still Todo...
1) add the support for facet.date.other (simple to do, just ran out of time to
day)
2) Date parsing needs to be enhanced to support date math on full date
strings, not just "NOW" that way if a client knows they are using
facet.date.gap of +1DAY and they get back a facet count for
1995-12-31T00:00:00.000Z they can easily generate a filter query for
field:[1995-12-31T00:00:00.000Z TO 1995-12-31T00:00:00.000Z+1DAY] to restrict
their results
3) rethink some of the "ft.toExternal(ft.toInternal(...))" type stuff going on
to ensure any date math strings are parsed... some of this may make sense as
lower level methods in the DateField class
Questions I'm not sure about...
* how much should we worry about gaps not dividing evenly between
start/end ... right now every range is exactly "gap" wide ... even if it goes
past the "end". Should the last gap end at "end" no matter what? (how would we
return that info in a way that's easy to parse and make a filter query out of)
* ranges currently include both end poinst ... Ideally we'd include one end
but not the other (so no overlap) but that makes filterqueries to restrict by
those rnages hard (even though queryparser supports inclusive or exclusive
ranges it doesn't support a mix/match of inclusive on one side and exclusive on
the other). maybe we can have an "interval" param which defaults to one
millisecond so ranges can allways be inclusive and still not overlap?
* what should happen if "end < start" or "gap < 0" ... maybe those should
be okay as long as both are true.
* should we support hardcoded default values for start, end, and gap? ...
for start it's easy to get the lowest value in the field, but what about gap
and end?
> Date based Facets
> -----------------
>
> Key: SOLR-258
> URL: https://issues.apache.org/jira/browse/SOLR-258
> Project: Solr
> Issue Type: New Feature
> Reporter: Hoss Man
> Attachments: date_facets.patch
>
>
> 1) Allow clients to express concepts like...
> * "give me facet counts per day for every day this month."
> * "give me facet counts per hour for every hour of today."
> * "give me facet counts per hour for every hour of a specific day."
> * "give me facet counts per hour for every hour of a specific day and
> give me facet counts for the
> number of matches before that day, or after that day."
> 2) Return all data in a way that makes it easy to use to build filter queries
> on those date ranges.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
