pluggable functions

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

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 <jonpiercegmail.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
>

On 9/18/07, Tom Hill <solr-listzvents.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 <jonpiercegmail.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
> >
>

On 9/18/07, Jon Pierce <jonpiercegmail.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

(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