lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Pierce" <>
Subject Re: pluggable functions
Date Tue, 18 Sep 2007 23:36:57 GMT
On 9/18/07, Tom Hill <> 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 <> wrote:
> >
> > I see Yonik recently opened an issue in JIRA to track the addition of
> > pluggable functions (
> > 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
> >

View raw message