[
https://issues.apache.org/jira/browse/SOLR-5707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908689#comment-13908689
]
Hoss Man commented on SOLR-5707:
--------------------------------
bq. But my understanding of function queries is they add to the score,
replacing it? With expressions, you could have 3 different expressions you sort
on, some of which might use the score, and get all 4 values back, in order to
evaluate and debug.
No, no ... value sources (aka function queries) can be used in all those same
ways in Solr,
Here's an example request that works today and uses value sources in 3
different ways:
* as an argument to the "boost" query parser which can wrap another query - in
this case the main query to affect the score (the use case you mentioned)
* as a psuedo field computed & returned for each doc in the response
* as a sort option
http://localhost:8983/solr/select?q={!boost%20f=div%28popularity,price%29}name:ipod&fl=id,score,popularity,price,weight,my_price:if%28inStock,price,-1%29&sort=div%28weight,price%29+asc,score%20desc
{code}
<result name="response" numFound="3" start="0" maxScore="1.7514601">
<doc>
<str name="id">MA147LL/A</str>
<float name="weight">5.5</float>
<float name="price">399.0</float>
<int name="popularity">10</int>
<float name="score">1.0320579</float>
<float name="my_price">399.0</float></doc>
<doc>
<str name="id">IW-02</str>
<float name="weight">2.0</float>
<float name="price">11.5</float>
<int name="popularity">1</int>
<float name="score">1.7514601</float>
<long name="my_price">-1</long></doc>
<doc>
<str name="id">F8V7067-APL-KIT</str>
<float name="weight">4.0</float>
<float name="price">19.95</float>
<int name="popularity">1</int>
<float name="score">1.0320579</float>
<long name="my_price">-1</long></doc>
</result>
{code}
The fact that all of these possibilities already exist in Solr as ways to use
value sources is why i suggested that having a new value source parser that
delegated to an expression (which, with the right bindings, might be able to
delegate to another value source) seemed to make so much sense to me.
If i understand your patch, it would allow "pre-compiled" script expressions to
be used in any place where fields could be used -- but the bindings (from
expression variables to underlying values) would have to be completely
pre-configured and static (because of the field limitations) correct?
If instead it was implemented as a value source, then the scripts could still
be pre-compiled at parser init, and there could still be static bindings
preconfigured on the valueSourceParser (and yes: these could certainly default
to including all field names), but other bindings could be configured so that
they could be specified at request time (either as additional arguments to the
"expression(...)" function, or possibly as inherited request params). I don't
think request time bindings would be possible with the FieldTYpe approach,
unless you did similar kludgy stuff like how RandomSortField expects to be used
as a DynamicField
bq. Implement expression integration similar to how function queries work,
possibly by adding "lang" or "type" or something like that to the QP so that
you could choose which language
that sort of blurs the line between a "fully dynamic" approach like what rmuir
was describing -- where the script syntax of the expression itself could be a
function argument, and the "static expressions, dynamic bindings" approach i'm
suggesting -- where the script expression is pre-configured & compiled at init,
and a "name" for the exprssion is specified at request time (similar to how you
would use a field name in the appraoch you are suggesting).
But yes: while we could easily have two value source parsers (one where the
input was an "expression name" for a pre-configured & pre-compiled expression,
and one where the input was "expression script" that would be evaluated on the
fly) we could also conceivably start with a value source parser for
pre-configured expressions and later expand it ot support expressions specified
in a request.
----
I guess my bottom line is: i certainly don't want to discourage you from your
ultimate goal. If you really feel like your "ComputedField" approach to
integrating expressions makes sense then so be it -- but it smells like a
missuse of the FieldType API to me. I _suspect_ that every usecase you are
trying to support here could also be supported via a value source parser, and
likely with a lot less shoe-horning need to make it work with the existing code.
Please consider it, and poke around with the value source parser APIs and think
about the examples i posted above for a bit. If you don't think it's a better
fit, then by all means keep going down your current path.
> Lucene Expressions in Solr
> --------------------------
>
> Key: SOLR-5707
> URL: https://issues.apache.org/jira/browse/SOLR-5707
> Project: Solr
> Issue Type: New Feature
> Reporter: Ryan Ernst
> Attachments: SOLR-5707.patch
>
>
> Expressions should be available for use in Solr.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
