[
https://issues.apache.org/jira/browse/LUCENE-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13767464#comment-13767464
]
Uwe Schindler commented on LUCENE-5207:
---------------------------------------
I think the branch is now in a quite good state.
I thought a little bit about extensibility of Javascript functions: The current
code is more or less "hardcoded" (although its configureable by a resource file
in the JAR). But this is not extensible by users (all private, you have to
rebuild JAR).
My idea would be to extend Bindings to also allow to get "methods". So one
could register a java.lang.reflect.Method binding. The code would check that it
only accepts "double" as parameters and returns a "double". Solr could then use
this to register stuff like "haversine". The compiler would be extended to
first try to get a binding for the function name (if it is a Method instance)
otherwise it falls back to the builtins.
Another thing to discuss (which is not yet a problem): If we allow function
binding and e.g. a Solr contrib from SolrResourceLoader would register a
function, the generated bytecode would fail to find the function: This is
because we use the classloader of the JavaScript module not the one of the
caller. We should either make this configureable or (I like this better): If
somebody registers a custom function we should include this into the
classloader, so the custom function impl class can be found by the JVM:
- the classloader of the custom function must be at least a child classloader
of the function module, otherwise it won't work at all. If all registered
custom functions don't have a common classloader hierarchy, throw exception.
- the child classloader check function is already part of Lucene, it is used
when loading SPIs.
If we make the classloader configureable (like it was in the original patch),
we must also check that our own classloader is a parent of the given one.
> lucene expressions module
> -------------------------
>
> Key: LUCENE-5207
> URL: https://issues.apache.org/jira/browse/LUCENE-5207
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Ryan Ernst
> Attachments: LUCENE-5207.patch
>
>
> Expressions are geared at defining an alternative ranking function (e.g.
> incorporating the text relevance score and other field values/ranking
> signals). So they are conceptually much more like ElasticSearch's scripting
> support (http://www.elasticsearch.org/guide/reference/modules/scripting/)
> than solr's function queries.
> Some additional notes:
> * In addition to referring to other fields, they can also refer to other
> expressions, so they can be used as "computed fields".
> * You can rank documents easily by multiple expressions (its a SortField at
> the end), e.g. Sort by year descending, then some function of score price and
> time ascending.
> * The provided javascript expression syntax is much more efficient than using
> a scripting engine, because it does not have dynamic typing (compiles to
> .class files that work on doubles). Performance is similar to writing a
> custom FieldComparator yourself, but much easier to do.
> * We have solr integration to contribute in the future, but this is just the
> standalone lucene part as a start. Since lucene has no schema, it includes an
> implementation of Bindings (SimpleBindings) that maps variable names to
> SortField's or other expressions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
