[jira] Updated: (SOLR-258) Date based Facets

["Hoss Man (JIRA)" <ji...@apache.org>]

     [ 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.