[
https://issues.apache.org/jira/browse/SOLR-5707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894986#comment-13894986
]
Hoss Man commented on SOLR-5707:
--------------------------------
bq. ... In this "static case" you compile up-front and re-use the same class
and get more advantages from e.g. hotspot: its as if you wrote a comparator in
java yourself. ...
Ok, yeah ... that makes sense, but I'm still wondering if a FieldType is really
the right approach here, as opposed to a ValueSourceParser where the
expressions are explicitly configured & pre-compiled, something along the lines
of....
{code}
<valueSourceParser
name="expression"class="solr.StaticExpresionValueSourceParser">
<lst name="bindings">
...
</lst>
<lst name="expressions">
<!-- used via function: expression(myexpr) -->
<str name="myexpr">price * 2</str>
...
</lst>
</valueSourceParser>
{code}
That seems like it could provide the same pre-compile/re-use advantage as the
ComputedField approach you're using here, w/o some of the baggage of schema &
FieldTypes -- ie: confusion people might have about whether a ComputedField
is/can/should-be indexed="true" or stored="true", the need for both a
<fieldType/> and a <field/> and what happens if you point 2 <field/>s at the
same <fieldType class="ComputedField" />, etc...
Basically I'm just trying to wrap my head around whether, from an abstraction
standpoint, it really makes sense for Expressions to be available as a
FieldType, and that we're not shoehorning them in.
For comparison: I think in hindsight, most people would agree our existing
"psuedo-fields" like ExternalFileField and RandomSortField are kind of
confusing and would probably make more sense as ValueSourceParser -- we just
didn't have that concept when those field types were created.
(It's also not clear to me if it can/should be possible for expressions to
_wrap_ other value sources (via a name mapping specified in the bindings i
guess?) in which case maybe that would be more straight forward via the
ValueSourceParser approach? .. not really sure.)
bq. Right, as I noted, I didn't want to chew that off here. But if you think it
is important to not make the craziness (FieldTypePluginLoader) any crazier, I
can take a stab.
Sorry, i wasn't trying to push you in that direction -- just tossing it out as
a suggestion.
Let me put it this way: if ComputedField is in fact the way to go, and if you
think introducing something like the marker interface i mentioned & using it in
your ComputedField would be simpler/cleaner/easier to understand then existing
ComputedField explicit hacks you had to put in your patch to make it work (i've
only skimmed it, and i only half thought through the idea so i'm not sure at
all) then we might as well generalize it. But: if it makes this issue more
complicated, then certainly just punt on it -- leave the patch like you've got
it and we can open a new issue to revisit the more generalized FieldType init
question.
> 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: [email protected]
For additional commands, e-mail: [email protected]
