[
https://issues.apache.org/jira/browse/LUCENE-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13767538#comment-13767538
]
Uwe Schindler commented on LUCENE-5207:
---------------------------------------
Hi Robert,
sorry for beeing a little bit confusing:
The two issues Classloader and Functions extensibility don't really have
something to do, they are mostly separate. With the current code and private
ctors and static functions, there is indeed no need for a custom classloader.
This is why I argued to remove it.
The classloader also does not have anything to do with Bindings. The bindings
was just an idea how to make it "easy" for the user to register own functions
in a non-static way. I was under the impression, that the bindings are availabe
while compiling. I don't want it "dynamic" - I wanted it still statically
compiled. The idea was to add the reflected Method to the bindings, so when
compiling the bytecode the method can be used (not per call). After reviewing
the code again, I can see that the bindings are not available at the time of
compiling - that was the misunderstanding, sorry (but it could still be fixed
to support this). It just looked elegant to treat a function like a binding.
The current patch is fine, let's commit it and do all other stuff like
extending custom functions later. For that we have to make the whole
JavascriptFunction interface public and non-static (currently its a
singleton-like factory). But this can be done in another issue.
The classloader problem is something that comes into the game when users are
able to register own functions. The problem here is that the classloader used
to load the ASM-generated class has the one of lucene-core as parent (because
we use the compiler's own classloader: this.getClass().getClassloader()). This
classloader does not necessarily have access to anything in a different
classloader (e.g. a plugin in ElasticSearch or Solr).
Finally its simple: Once we allow foreign, user-defined functions, we must add
the Classloader argument to the compiler again, otherwise you cannot register
methods from classes of foreign classloaders. An alternative would be to let
the compiler figure out himself by passing a list of java.lang.reflect.Method
and it chooses the correct classloader automatically.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
