> 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 .
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.
> In practice: people either don't notice, don't care, or find it easy
> enough to add/subtract 1 millisecond to their times to get the behavior
> they want.
>
The main problem here is that this time change would need to be done at index
time - and is essentially 'tampering' with
the data (e.g. if the timestamp is extracted from a security field that needs
to be stored unmodified, or is needed/used
for another purpose).
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've not looked at the DateMathParser code in great detail, but maybe adding
MILLIS logic could be the most
straighforward option, as then the 'nuances' of query parser changes (curent
and future), 'before', 'after' et al.
are handled as they are now. Anyone wishing to make use of such new behaviour,
well, they'd have to use MILLIS.
Peter
_________________________________________________________________
Got a cool Hotmail story? Tell us now
http://clk.atdmt.com/UKM/go/195013117/direct/01/
