On 5/7/2018 9:51 AM, manuj singh wrote:
> I am kind of confused how must clause(+) behaves with the filter queries.
> e.g i have below query:
> q=*:*&fq=+{!frange cost=200 l=NOW-179DAYS u=NOW/DAY+1DAY incl=true
> incu=false}date
>
> So i am filtering documents which are less then 179 old days.
> So e.g if now is May 7th, 10.23 cst,2018, i should only see documents which
> have date > Nov 9th, 10.23 cst, 2017.
>
> However with the above query i am also seeing documents which are done on
> Nov 5th,2017 (which seems like it is returning some docs from filter cache.
> which is wired because in my date range for the start date  i am using
> NOW-179DAYS and
> Now is changing every time, so it shouldn't go to filtercache as every new
> request will have  a different time stamp. )
>
> However if i remove the + from the filter query it seems to work fine.

I'm not sure that trying to use the + with the frange query makes any
sense.  For one thing, putting anything before the localparams (which is
the {!stuff otherstuff} syntax) probably causes Solr to not correctly
interpret the localparams syntax.  Typically localparams must be at the
very beginning of the query.  Adding a plus to a single-clause query
like that is not necessary.  Queries with one clause will effectively be
interpreted as having the +/MUST on that clause.

> I am mostly thinking it seems to be a filtercache issue but not sure how i
> prove that.
>
> Our auto soft commit is 500 ms , so every 0.5 second we should have a new
> searcher open and cache should be flushed.

A commit interval that low could result in some big problems.  I hope
the autowarmCount setting on all your caches is zero.  If it's not,
you're going to want to have a much longer interval than 500 milliseconds.

> Something is not right and i am not able to figure out what. Has some one
> seen this kind of issue before ?
>
> If i move the query from fq to q then also it works fine.
>
> One more thing when i put debug query i see the following in the parse query
>
> *"QParser": "LuceneQParser", "filter_queries": [ "+{!frange cost=200
> l=NOW-179DAYS u=NOW/DAY+1DAY incl=true incu=false}date", "-_parent_:F" ],
> "parsed_filter_queries": [
> "+FunctionRangeQuery(ConstantScore(frange(date(date)):[NOW-179DAYS TO
> NOW/DAY+1DAY}))", "-_parent_:false" ]*
>
> So in the above i do not see the date getting resolved to an actual time
> stamp.
>
> However if i change the syntax of the query to not use frange and local
> params i see the transaction date resolving into correct timestamp.
>
> So for the following query
> q=*:*&fq=+date:[NOW-179DAYS TO NOW/DAY+1DAY]
>
> i see the following in the debug query, and see the actualy timestamp:
> "QParser": "LuceneQParser", "filter_queries": [ "date:[NOW-179DAYS TO
> NOW/DAY+1DAY]", "-_parent_:F" ], "parsed_filter_queries": [
> "date:[1510242067383
> TO 1525737600000]", "-_parent_:false" ],

If the filter you're trying to use is this kind of simple date range, I
would stick with lucene and not use localparams to switch to another
parser.  I would also set the low value of the range to NOW/DAY-179DAYS
so there's at least a chance that caching will be effective.  Also, as
mentioned, because this example only has one query clause, adding + is
unnecessary.  It might become necessary if you have multiple query
clauses ... but in that case, you're not likely to be using something
like frange.

Thanks,
Shawn

Reply via email to