[ 
https://issues.apache.org/jira/browse/SOLR-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855133#action_12855133
 ] 

Chris Harris commented on SOLR-1871:
------------------------------------

bq. Yep, makes sense. Some of the older FunctionQueries predate the ability of 
the parser to generalize more (one had to know if one was parsing a constant or 
a function). It might make sense to generalize the map function rather than 
have two functions?

Yes, having a single map sounds less confusing from a user perspective.

The reason I started by forking map into map and mapf was that I was worried 
about performance; I assumed (apparently incorrectly?) that hard-coding certain 
things as float constants had been done as a performance optimization. Are you 
implying that the approach taken by this fmap code is probably fast enough to 
be the standard implementation of map?

And what if it were taken to the extreme of making all arguments for all 
function queries ValueSource compatible? (That is, what if all functions used 
fp.parseValueSource() for all their arguments, and parsed none of them with 
fp.parseFloat()?) Does _that_ start to sound inefficient?


> Function Query "map" variant that allows "target" to be an arbitrary 
> ValueSource
> --------------------------------------------------------------------------------
>
>                 Key: SOLR-1871
>                 URL: https://issues.apache.org/jira/browse/SOLR-1871
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>    Affects Versions: 1.4
>            Reporter: Chris Harris
>         Attachments: SOLR-1871.patch, SOLR-1871.patch
>
>
> Currently, as documented at http://wiki.apache.org/solr/FunctionQuery#map, 
> the "target" of a map must be a floating point constant. I propose that you 
> should have at least the option of doing a map where the target is an 
> arbitrary ValueSource.
> The particular use case that inspired this is that I want to be able to 
> control how missing date fields affected boosting. In particular, I want to 
> be able to use something like this in my function queries:
> {code}
> map(mydatefield,0,0,ms(NOW))
> {code}
> But this might have other uses.
> I'll attach an initial implementation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to