[
https://issues.apache.org/jira/browse/SOLR-5707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17948765#comment-17948765
]
David Smiley edited comment on SOLR-5707 at 5/7/25 6:59 PM:
------------------------------------------------------------
I'm very interested in adding this to Solr. The overall objective is to make
it easy to define simple expressions on the Solr side without hand-rolling Java
code (e.g. a custom DocTransformer or ValueSourceParser).
-The DocTransformer (AKA for pseudo-fields) side is perhaps non-obvious but it
could allow processing text/string data to compute a number from it instead of
returning that whole value to the client and the client doing something with
it. Example: {{body_txt.toLowerCase().includes($query.toLowerCase())}}
yielding a boolean as 0 or 1. There's even a performance/scalability argument
for doing this, especially as distributed-search (sharding) is considered for
text fields, avoiding moving lots of data (disclaimer: just a hypothesis).
FWIW a colleague expressed a strong preference that some of our logic be done
on the Solr side even if the client could do similar logic with the returned
text – separation of concerns for relevancy oriented features.-
Edit: the Lucene Expressions module is such an extreme subset of JavaScript
that it doesn't support Strings; it's really limited to {{double}} numbers.
was (Author: dsmiley):
I'm very interested in adding this to Solr. The overall objective is to make
it easy to define simple expressions on the Solr side without hand-rolling Java
code (e.g. a custom DocTransformer or ValueSourceParser).
The DocTransformer (AKA for pseudo-fields) side is perhaps non-obvious but it
could allow processing text/string data to compute a number from it instead of
returning that whole value to the client and the client doing something with
it. Example: {{body_txt.toLowerCase().includes($query.toLowerCase())}}
yielding a boolean as 0 or 1. There's even a performance/scalability argument
for doing this, especially as distributed-search (sharding) is considered for
text fields, avoiding moving lots of data (disclaimer: just a hypothesis).
FWIW a colleague expressed a strong preference that some of our logic be done
on the Solr side even if the client could do similar logic with the returned
text – separation of concerns for relevancy oriented features.
> 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
> Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-5707.patch, SOLR-5707_vsp.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Expressions should be available for use in Solr.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
