Re: pluggable functions
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 [EMAIL PROTECTED] 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
On 9/18/07, Tom Hill [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
On 9/18/07, Jon Pierce [EMAIL PROTECTED] 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 ListValueSource 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
(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 ListValueSource 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
