: > should we be inclusive of the lower or the upper? ... even if we make it
: > an option, how should it apply to the "first" and "last" ranges computed?
: > do the answers change if facet.date.other includes "before" and/or "after"
: > should the "between" option be inclusive of both end points as well?
: I guess to be consistent, the 'inclusiveness' should be intrsinically handled
in
: detection of '[', '{' and/or ']', '}' -- i.e. match the facet.date field with
the corresponding field
: in the query - e.g.: q= *:* AND timestamp:[then TO now}&date.facet=timestamp .
...that only works if the datefield being faceted on is included in the --
which is frequently not the case, particularly on the "first" request of a
session, where you want to face on date, buthte user has not yet made any
attempt to restrict by any of those facets.
: If no such token exists in the query, perhaps the date.facet token parsing
could process
: an option ala: date.facet=[timestamp} to explicitly set the edge behaviour,
or to override a match
: in the query parser tokenization.
:
: This way, there's no new explicit option; it would work with existing queries
(no extra []{}'s = default behaviour);
: and people could easily add it if they need custom edge behaviour.
I suppose ... but it still doesn't address some of hte outstanding
questions i pointed out before (handling the first/last range in the block
... ie: "i want inclusive of the lower, exclusive of hte upper, except for
the last range which should be inclusive of both). Personally i think
addign a new option is just as clear as adding markup to the "date.facet"
param parsing ... the less we make assumptions about what "special
characters" people have in their fieldnames the better.
: Another way to deal with it is to add MILLISECOND logic to the
DateMathParser. Then the '1ms' adjustment
: at one and/or the other could be done by the caller at query time, leaving
the stored data intact, and leaving
: the server-side date faceting as it is. In fact, this can be done today using
SECOND, but can be a problem if:
: - You're using HOURS or DAYS and don't want to convert to SECONDS each time,
or
: - You need granularity to the SECOND
I don't follow you at all ... yes this can be done today, but i don't
understand what you mean about needing to convert to seconds, or requiring
second granularity.
If you don't index with millisecond precision, then no matter what
precision you index with, this example would let you get ranges including
the "lower" bound, but not the upper bound of each range using a 1ms
"fudge" ...
facet.date=timestamp
facet.date.start=NOW/DAY-5DAYS-1MILLI
facet.date.end=NOW/DAY+1DAY-1MILLI
facet.date.gap=+1DAY
Brainstorming a bit...
I think the semantics that might make the most sense is to add a
multivalued "facet.date.include" param that supports the following
options: all, lower, upper, edge, outer
- "all" is shorthand for lower,upper,edge,outer and is the default
(for back compat)
- if "lower" is specified, then all ranges include their lower bound
- if "upper" is specified, then all ranges include their upper bound
- if "edge" is specified, then the first and last ranges include
their edge bounds (ie: lower for the first one, upper for the last
one) even if the corrisponding "upper"/"lower" option is not
specified.
- the "between" count is inclusive of each of the start and end
bounds iff the first and last range are inclusive of them
- the "before" and "after" ranges are inclusive of their respective
bounds if:
- "outer" is specified ... OR ...
- the first and last ranges don't already include them
so assuming you started with something like...
facet.date.start=1 facet.date.end=3 facet.date.gap=+1 facet.date.other=all
...your ranges would be...
[1 TO 2], [2 TO 3] and [* TO 1], [1 TO 3], [3 TO *]
w/ facet.date.include=lower ...
[1 TO 2}, [2 TO 3} and [* TO 1}, [1 TO 3}, [3 TO *]
w/ facet.date.include=upper ...
{1 TO 2], {2 TO 3] and [* TO 1], {1 TO 3], {3 TO *]
w/ facet.date.include=lower&facet.date.include=edge ...
[1 TO 2}, [2 TO 3] and [* TO 1}, [1 TO 3], {3 TO *]
w/ facet.date.include=upper&facet.date.include=edge ...
[1 TO 2], {2 TO 3] and [* TO 1}, [1 TO 3], {3 TO *]
w/ facet.date.include=upper&facet.date.include=outer ...
{1 TO 2], {2 TO 3] and [* TO 1], {1 TO 3], [3 TO *]
...etc.
what do you think?
-Hoss
