Solr
  1. Solr
  2. SOLR-397

options for dealing with range endpoints in date facets

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1, 4.0-ALPHA
    • Component/s: None
    • Labels:
      None

      Description

      Date faceting should support configuration for controlling how edge boundaries are dealt with.

      1. SOLR-397.patch
        24 kB
        Hoss Man
      2. SOLR-397.patch
        25 kB
        Hoss Man

        Issue Links

          Activity

          Hoss Man created issue -
          Hoss Man made changes -
          Field Original Value New Value
          Link This issue depends on SOLR-355 [ SOLR-355 ]
          Hoss Man made changes -
          Description as discussed in email...
          http://www.nabble.com/Re%3A-Date-facetting-and-ranges-overlapping-p12928374.html

          : I'm now using date facetting to browse events. It works really fine
          : and is really useful. The only problem so far is that if I have an
          : event which is exactly on the boundary of two ranges, it is referenced
          : 2 times.

          yeah, this is one of the big caveats with date faceting right now ... i
          struggled with this a bit when designing it, and ultimately decided to
          punt on the issue. the biggest hangup was that even if hte facet counting
          code was smart about making sure the ranges don't overlap, the range query
          syntax in the QueryParser doesn't support ranges that exclude one input
          (so there wouldn't be a lot you can do with the ranges once you know the
          counts in them)

          one idea i had in SOLR-258 was that we could add an "interval" option that
          would define how much to add to the "end" or one range to get the "start"
          of another range (think of the current implementation having interval
          hardcoded to "0") which would solve the problem and work with range
          queries that were inclusive of both endpoints, but would require people to
          use "-1MILLI" a lot.

          a better option (assuming a query parser change) would be a new option
          thta says wether each computed range should be enclusive of the low poin,t
          the high point, both end points, neither end points, or be "smart" (where
          smart is the same as "low" except for the last range where the it includes
          both)

          (I think there's already a lucene issue to add the query parser support, i
          just haven't had time to look at it)

          The simple workarround: if you know all of your data is indexed with
          perfect 0.000second precision, then put "-1MILLI" at the end of your start
          and end date faceting params.
          Date faceting should support configuration for controlling how edge boundaries are dealt with.
          Hoss Man made changes -
          Link This issue incorporates SOLR-1402 [ SOLR-1402 ]
          Hoss Man made changes -
          Attachment SOLR-397.patch [ 12443150 ]
          Hoss Man made changes -
          Attachment SOLR-397.patch [ 12443353 ]
          Hoss Man made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 1.5 [ 12313566 ]
          Resolution Fixed [ 1 ]
          Hoss Man made changes -
          Assignee Hoss Man [ hossman ]
          Hoss Man made changes -
          Fix Version/s 4.0 [ 12314992 ]
          Fix Version/s 1.5 [ 12313566 ]
          Hoss Man made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Hoss Man made changes -
          Fix Version/s 3.1 [ 12314371 ]
          Hoss Man made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Grant Ingersoll made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Link This issue depends on SOLR-355 [ SOLR-355 ]
          Gavin made changes -
          Link This issue depends upon SOLR-355 [ SOLR-355 ]

            People

            • Assignee:
              Hoss Man
              Reporter:
              Hoss Man
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development