pluggable functions

[Jon Pierce <jo...@gmail.com>]

I see Yonik recently opened an issue in JIRA to track the addition of
pluggable functions (https://issues.apache.org/jira/browse/SOLR-356).
Any chance this will be implemented soon?  It would save users like me
from having to hack the Solr source or write custom request handlers
for trivial additions (e.g., adding a distance function), not to
mention changes to downstream dependencies (e.g., solr-ruby).  Perhaps
a reflection-based approach would do the trick?

- Jon

Re: pluggable functions

[Chris Hostetter <ho...@fucit.org>]

(NOTE: this discussion probably makes more sense on solr-dev.  future 
replies should probably go there, or in  SOLR-334.)

: The parser is a quick hack I threw together, and any value source
: factories should not be exposed to it.  It seems like either
: 1) a value source factory would expose the types it expects
: or
: 2) a value source factory would take a List<ValueSource> and throw a
: ParseException if it didn't get what it expected
: 
: Reflection might be fine if the cost of construction via reflection
: ends up being small compared to the parsing itself.

Another option is to assume that if people are writing their own 
ValueSoures and loading them into solr as plugins, they could write their 
"FunctionParser" subclass that knows about those ValueSoures and then 
register that FunctionParser -- the key being to make it easy to subclass 
a FunctionParser to add your own functions (without needing to cut/paste a 
tone of stuff like you do now)

To me the key differentiator between something like this, and something 
like Tokenizer/TokenFilter factories is that with those, you want to be 
able to mix/match them at run time a lot -- but i'm guessing once you 
write a ValueSource and you want the function parser to use whenever it 
sees "foo(...)" that's not something you really need to change with each 
Solr install (or have one function parser for one request handler, and a 
different one for another reuqest handler)




-Hoss

Re: pluggable functions

[Yonik Seeley <yo...@apache.org>]

On 9/18/07, Jon Pierce <jo...@gmail.com> wrote:
> Reflection could be used to look up and invoke the constructor with
> appropriately-typed arguments.  If we assume only "primitive" types
> and ValueSources are used, I don't think it would be too hard to craft
> a drop-in replacement that works with existing implementations.  In
> any case, the more flexible alternative would probably be to do as
> you're suggesting (if I understand you correctly) -- let the function
> handle the parsing,

The parser is a quick hack I threw together, and any value source
factories should not be exposed to it.  It seems like either
1) a value source factory would expose the types it expects
or
2) a value source factory would take a List<ValueSource> and throw a
ParseException if it didn't get what it expected

Reflection might be fine if the cost of construction via reflection
ends up being small compared to the parsing itself.

-Yonik

Re: pluggable functions

[Jon Pierce <jo...@gmail.com>]

On 9/18/07, Tom Hill <so...@zvents.com> wrote:
> Hi -
>
> I'm not sure what you mean by a reflection based approach, but I've been
> thinking about doing this for a bit, since we needed it, too.

Reflection could be used to look up and invoke the constructor with
appropriately-typed arguments.  If we assume only "primitive" types
and ValueSources are used, I don't think it would be too hard to craft
a drop-in replacement that works with existing implementations.  In
any case, the more flexible alternative would probably be to do as
you're suggesting (if I understand you correctly) -- let the function
handle the parsing, with a base implementation and utilities provided.
 The class names would be mapped to function names in the config file.

- Jon

> I'd just thought about listing class names in the config file. The functions
> would probably need to extend a subclass of ValueSource which will handle
> argument parsing for the function, so you won't need to hard code the
> parsing in a VSParser subclass. I think this might simplify the existing
> code a bit.
>
> You might have to do a bit of reflection to instantiate the function. Did
> you have an alternate approach in mind? Are there any other things this
> would need to do?
>
> Is anyone else working on this?
>
> Tom
>
>
>
>
> On 9/18/07, Jon Pierce <jo...@gmail.com> wrote:
> >
> > I see Yonik recently opened an issue in JIRA to track the addition of
> > pluggable functions (https://issues.apache.org/jira/browse/SOLR-356).
> > Any chance this will be implemented soon?  It would save users like me
> > from having to hack the Solr source or write custom request handlers
> > for trivial additions (e.g., adding a distance function), not to
> > mention changes to downstream dependencies (e.g., solr-ruby).  Perhaps
> > a reflection-based approach would do the trick?
> >
> > - Jon
> >
>

Re: pluggable functions

[Tom Hill <so...@zvents.com>]

Hi -

I'm not sure what you mean by a reflection based approach, but I've been
thinking about doing this for a bit, since we needed it, too.

I'd just thought about listing class names in the config file. The functions
would probably need to extend a subclass of ValueSource which will handle
argument parsing for the function, so you won't need to hard code the
parsing in a VSParser subclass. I think this might simplify the existing
code a bit.

You might have to do a bit of reflection to instantiate the function. Did
you have an alternate approach in mind? Are there any other things this
would need to do?

Is anyone else working on this?

Tom




On 9/18/07, Jon Pierce <jo...@gmail.com> wrote:
>
> I see Yonik recently opened an issue in JIRA to track the addition of
> pluggable functions (https://issues.apache.org/jira/browse/SOLR-356).
> Any chance this will be implemented soon?  It would save users like me
> from having to hack the Solr source or write custom request handlers
> for trivial additions (e.g., adding a distance function), not to
> mention changes to downstream dependencies (e.g., solr-ruby).  Perhaps
> a reflection-based approach would do the trick?
>
> - Jon
>