: 2) lame :\
Why do you say that? ... it's a practical limitation -- for each document
a function is computed, and then the result of that function is compared
against the (fixed) upper and lower bounds.
In situations where you want the something like the lower bound of the
range comparison to be another function relative to the document, that's
equivilent to "unwinding" that lower bound function and rolling it into
the function you are testing -- just like i did in the example i posted in
"#4" of my email (below)
By requiring that the uper and lower bounds be fixed, the common case can
be optimized, but cases like that one can stll be supported. if the lower
& upper bound params supported arbitrary functions, the implementation
would be a lot more complex -- slower for hte common case, and hte same
speed for uncommon cases like what you're describing.
: 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
To be very clear: even if what you were trying to do worked as you wrote
it, adding an upper bound wouldn't change the fact that the comparison you
were trying ot make in your query doesn't match the problem statement in
your question, and doesn't make sense in general -- you need to compare
the field value with 10% of some OTHER input value -- not 10% of itself.
Adding an upper bound that was similar to hte lower bound you were trying
would have simply prevented any docs from mathcing at all.
: > : 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/
: >
:
-Hoss
http://www.lucidworks.com/
