[
https://issues.apache.org/jira/browse/SOLR-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512775
]
Tristan Vittorio commented on SOLR-258:
---------------------------------------
> 4) my hesitation about renaming "gap" to "interval" is that i wanted to leave
> the door open
> for a sperate "interval" option (to define a "gap between the gaps" so
> to speak) later
> should it be desired ... see the "questions" i listed when opening the
> bug.
I do like the idea of having an "interval" between "gaps", however to me it
would make more sense to reverse the meanings of these parameters to have
"gaps" between "intervals". Regardless, as long as it's clearly documented, it
shouldn't make any difference what you name them.
> 5) i don't think this code makes sense for non-linear intervals ...
It might be better to keep the logic simple and as-is for now so you can commit
it. Having a "facet.range" parameter or some way to specify multiple date
facets on a single field would be useful in the future.
> 7) my prefrence is for every count to cover a range of exactly "gap" but i
> can definitely see where
> having a hard cutoff of "end" is usefull, so i'll make it an option ...
> name suggestions?
Just thinking through this further, rather than specifying both start and end
times, it might be more precise to specify a single start time, a gap, and a
gap "count" (how many "gaps" to include), this will avoid the problem of the
last "gap" going past the "end" date.
I find it much easier to criticize other people's naming conventions than to
come up with good ones myself, however I'll offer "hardend" (true | false) as
an interim name, hopefully someone can think of a better one.
> i'll make sure to echo the value of "end" as well so it's easy to build
> filter queries for that last range ...
> probably should have it anyway to build filter queries on between and after.
It might be helpful to output the value of "start" also, especially if it was
specified as an offset of NOW.
> should the ranges used to compute the between and after counts depend on
> where the last range ended or on the literal "end" param?
I suppose this will depend on the value of "hardend", if true then use the
"end" value, otherwise use the end of the last gap.
> 8) the NOW variance really bugs me ...
Sounds like a pretty nasty problem affecting more than just this date facet. I
know Solr is not a RDBMS, but I always assumed that NOW would be constant
throughout the life of a query. Definitely something to think about as a
seperate issue though.
> Date based Facets
> -----------------
>
> Key: SOLR-258
> URL: https://issues.apache.org/jira/browse/SOLR-258
> Project: Solr
> Issue Type: New Feature
> Reporter: Hoss Man
> Assignee: Hoss Man
> Attachments: date_facets.patch, date_facets.patch, date_facets.patch,
> date_facets.patch, 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.
