[
https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536681
]
Yonik Seeley commented on SOLR-351:
-----------------------------------
Thanks for the review JJ, I had missed it earlier somehow (I just committed
this code).
re: specifying filename... yes, I thought it might possibly be useful in the
future, esp being able to specify somewhere different than the index directory.
I simply left it out now because nothing is lost in deferring it.
{quote}
2. Is ExternalFieldField useful apart from being used as input to function
queries, e.g. could one sort or facet against it?
{quote}
Not currently. Perhaps in the future it would be possible to make it
searchable... not sure. And it seems like a good idea to allow sorting by a
ValueSource in the future. Faceting: yes, I think so (again, in the future).
{quote}
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
{quote}
Hmmm, I hadn't thought of hooking it directly via a new type of function, but
that would work.
add(1, filevalues("myexternalfilename","float") )
I'm not sure I understand the form you picked though (a ValueSource param to
filemap).
{quote}
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.
{quote}
Right, Lucene doesn't allow write access to the FieldCache.
{quote}
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"/>
{quote}
So a FunctionField would be a shortcut or alias to any function query
expression... that's a pretty interesting idea.
Since the signature for getValueSource now includes the QParser, this should be
doable.
> 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.
