[
https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535321
]
J.J. Larrea commented on SOLR-351:
----------------------------------
My apologies for these last-minute peanut-gallery comments, and especially if
they're completely off-target (I've not yet used Function Queries), but
reviewing the patch raised these questions and ideas:
1. Why force a 1:1 mapping between the fieldname and the filename? Could there
ever be a be a situation where multiple fields would want to share the same
file, e.g. if if the file is a sampling of a generic weighting function, or
even if field-specific if it needs to be shared across multiple Solr
instances/cores?
Within the current structure, an extra file="<baseFile>" argument to
ExternalFieldField and FileFloatSource couldn't hurt; it could still default to
external_<fieldname>, relative paths could still resolve to ffs.indexDir, and
the getLatestFile extension logic could still be applied, but specified names
with relative or absolute paths would be allowed.
2. Is ExternalFieldField useful apart from being used as input to function
queries, e.g. could one sort or facet against it?
2a. If not (or even if so), couldn't one get enhanced flexibility and
simplicity by creating a function interface to FileFloatSource that uses a
sub-ValueSource to obtain key values? That way the domain of the mapping
function isn't limited to a literal set of Terms. For example, a function of
the form
filemap( <keyFieldName>[, "baseFilePath" )
could be applied as, for example,
boost( filemap( keyField ) )
boost( filemap( div( ord( someField ), const( 1426 ) ),
"/var/data/termBooster" ) )
I'm thinking something like this (added to FunctionQParser):
vsParsers.put("filemap", new VSParser() {
ValueSource parse(FunctionQParser fp) throws ParseException {
ValueSource source = fp.parseValSource();
fp.sp.expect(",");
String base = fp.sp.getQuotedString();
(would also want to get the default in there)
return new FileFloatFunction(source, base);
}
});
One would think a FileFloatFunction could extend FieldCacheSource, but I assume
there was a good reason the FC code was duplicated rather than references, e.g.
limited access.
2b. If the external file could be useful for sorting/faceting, and if it could
be implemented as a Function as above, then perhaps ExternalFieldField could be
recast as a more general FunctionField which takes a QueryParser.StrParser
string in an attribute?
<fieldType name="file" class="solr.FunctionField" expression="filemap(id)"
stored="false" indexed="false" valType="float"/>
Is there any sense to these (even if the scope is way too large to be
implemented in the foreseeable future)?
I also have some thoughts on SOLR-334 which I'll write up in a few days.
> external value source
> ---------------------
>
> Key: SOLR-351
> URL: https://issues.apache.org/jira/browse/SOLR-351
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
> Attachments: ExternalFileField.patch
>
>
> Need a way to rapidly do a bulk update of a single field for use as a
> component in a function query (no need to be able to search on it).
> Idea: create an ExternalValueSource fieldType that reads it's values from a
> file. The file could be simple id,val records, and stored in the index
> directory so it would get replicated.
> Values could optionally be updated more often than the searcher
> (hashCode/equals should take this into account to prevent caching issues).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
