[
https://issues.apache.org/jira/browse/SOLR-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512559
]
Hoss Man commented on SOLR-258:
-------------------------------
1) i'm happy to break out the FacetParams into their own interface ... but i'd
like to track that in a separate refactoring commit (since the existing facet
params are already in SolrParams)
2) i clearly anticipated the FacetDateOther.get( bogus ) problem .. but for
some reason i thought it returned null ... i'll fix that.
3) i actually considered before, between, and after originally but decided they
were too long (i was trying to find a way to make "start" shorter as well ...
but two people thinking there better convinces me.
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.
5) i don't think this code makes sense for non-linear intervals ... the problem
i'm really trying to solve here is using 3 params to express equal date
divisions across an arbitrarily long time scale. for the example you listed
simple facet.query options probably make more sense
(allthough you do have me now thinking that a another good faceting option
would be some new "facet.range" where many values can be specified, they all
get sorted and then ranges are built between each successive value ... bt that
should be a seperate issue)
6) i want to make start and end optional, but for now i can't think of a
clean/fast way to do end ... and we can always add defaults later.
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?
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.
should the ranges used to compute the between and after counts depend on where
the last range ended or on the literal "end" param?
8) the NOW variance really bugs me ... back when i built DateMathParser i
anticipated this by making the parser have a fixed concept of NOW which could
be used to parse multiple strings but i don't kow why i didn't consider it when
working on this new patch.
the real problem is that right now DateField is relied on to do all hte
parsing, and a single instance can't have a fixed notion of "NOW" ... it builds
a new DateMathParser each time ... i think i'm going ot have to do some heavily
refactoring to fix this, which is annoying -- but i don't want to commit
without fixing this, even if it takes a while any bug that can produce an "off
by 1 millisecond" discrepancy should die a horrible horrible freaking death.
> 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.
