lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Updated: (SOLR-258) Date based Facets
Date Fri, 08 Jun 2007 00:51:28 GMT

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


Mime
View raw message