1) ooo, i see
2) lame :\
3) right. i hadn't bothered with the upper limit yet simply for sake of
less complexity / chance to fk it up. wanted to get the function working
for lower before worrying about adding u= and getting the query refined
4) very good point about just doing it client side. i know in one instance
(and the most immediate one as far as product development/goals is
concerned) this would certainly be both easily doable and desired. there
are other cases where i could see us trying to find a document and then
based off of its returned sizes trying to find a range of items like it
(via morelikethis i assume?).
in either case, point 4 stands and i probably got carried away in the
learning process w/o stepping back to think about real life implementation
and workarounds.
thanks!
--
*John Blythe*
Product Manager & Lead Developer
251.605.3071 | j...@curvolabs.com
www.curvolabs.com
58 Adams Ave
Evansville, IN 47713
On Thu, May 28, 2015 at 3:06 PM, Chris Hostetter <hossman_luc...@fucit.org>
wrote:
>
> : Expected identifier at pos 29 str='{!frange l=sum(size1, product(size1,
> : .10))}size1
> :
> : pos 29 is the open parenthesis of product(). can i not use a function
> : within a function? or is there something else i'm missing in the way i'm
> : constructing this?
>
> 1) you're confusing the parser by trying to put whitespace inside of a
> local param (specifically the 'l' param) w/o quoting the param value .. it
> things that you want "sum(size1" to be the value of the "l" param, and
> then it doesn't know what to make of "product(size1" as a another local
> param that it can't make sense of.
>
> 2) if you remove the whitespace, or quote the param, that will solve that
> parsing error -- but it will lead to a new error from
> ValueSourceRangeFilter (ie: "frange") because the "l" param doesn't
> support arbitrary functions -- it needs to be a concrete number.
>
> 3) even if you could pass a function for the "l" param, conceptually what
> you are asking for doesn't really make much sense ... you are asking solr
> to only return documents where the value of the "size1" field is in a
> range between X and infinity, where X is defined as the sum of the value
> of the "size1" field plus 10% of the value of the "size1" field.
>
> In other words: "give me all docs where S * 1.1 <= S"
>
> Basically you are asking it to return all documents with a negative value
> in the "size1" field.
>
>
> 4) your original question was about filtering docs where the value of a
> field was inside a range of +/- X% of a specified value. a range query
> where you computed the lower/upper bounds bsed on that percentage in the
> client is really the most straight forward way to do that.
>
> the main reason to consider using frange for something like this is if you
> wnat to filter documents based on the reuslts of a function over multiple
> fields. (ie: "docs where the price field divided by the quantity_included
> field was within a client specified range")
>
> adimitedly, you could do something like this...
>
> fq={!frange u=0.10}div(abs(sub($target,size1)),$target)&target=345
>
> ...which would tell solr to find you all documents where the "size1" field
> was within 10% of the target value (345 in this case) -- ie: "310.5 <=
> size1 <= 379.5)
>
> however it's important to realize that doing something like this is going
> to be less inefficient then just computing the lower/upper range
> bounds in the client -- because solr will be evaluating that function for
> every document in order to make the comparison. (meanwhile you can
> compute the upper and lower bounds exactly once and just let solr do the
> comparisons)
>
>
> -Hoss
> http://www.lucidworks.com/
>
