You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Yonik Seeley (JIRA)" <ji...@apache.org> on 2007/09/10 05:10:29 UTC
[jira] Created: (SOLR-351) external value source
external value source
---------------------
Key: SOLR-351
URL: https://issues.apache.org/jira/browse/SOLR-351
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
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.
[jira] Resolved: (SOLR-351) external value source
Posted by "Shalin Shekhar Mangar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shalin Shekhar Mangar resolved SOLR-351.
----------------------------------------
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Yonik Seeley
This issue has been fixed by Yonik in revision 587098 and released with 1.3
> external value source
> ---------------------
>
> Key: SOLR-351
> URL: https://issues.apache.org/jira/browse/SOLR-351
> Project: Solr
> Issue Type: New Feature
> Components: search
> Reporter: Yonik Seeley
> Assignee: Yonik Seeley
> Fix For: 1.3
>
> 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.
[jira] Updated: (SOLR-351) external value source
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Yonik Seeley updated SOLR-351:
------------------------------
Attachment: ExternalFileField.patch
Attaching patch (separated out from pluggable query parsers, but still depends on it).
I'll commit shortly barring objections.
> 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.
[jira] Commented: (SOLR-351) external value source
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531988 ]
Yonik Seeley commented on SOLR-351:
-----------------------------------
OK, the latest SOLR-344 patch includes external value source.
Here is what the fieldType in the schema looks like:
<fieldType name="file" class="solr.ExternalFileField" keyField="id" defVal="1" stored="false" indexed="false" valType="float"/>
* keyField will normally be the unique key field, but it doesn't have to be.
** it's OK to have a keyField value that can't be found in the index
** it's OK to have some documents without a keyField in the file (defVal is used as the default)
** it's OK for a keyField value to point to multiple documents (no uniqueness requirement)
* valType is a reference to another fieldType to define the value type of this field (must currently be FloatField (float))
The format of the external file is simply
keyFieldValue=floatValue
keyFieldValue=floatValue
Solr looks for the external file in the index directory under the name of
external_<filename> or external_<filename>.*
If any files of the latter pattern appear, the last (after being sorted by name) will be used and previous versions will be deleted. This is to help support systems where one may not be able to overwrite a file (like Windows, if the file is in use).
If the external file has already been loaded, and it is changed, those changes will not be visible until a commit has been done.
The external file may be sorted or unsorted by the key field, but it will be substantially slower (untested) if it isn't sorted.
> external value source
> ---------------------
>
> Key: SOLR-351
> URL: https://issues.apache.org/jira/browse/SOLR-351
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
>
> 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.
[jira] Issue Comment Edited: (SOLR-351) external value source
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531988 ]
yseeley@gmail.com edited comment on SOLR-351 at 10/15/07 3:25 PM:
-------------------------------------------------------------
OK, the latest SOLR-334 patch includes external value source.
Here is what the fieldType in the schema looks like:
<fieldType name="file" class="solr.ExternalFileField" keyField="id" defVal="1" stored="false" indexed="false" valType="float"/>
* keyField will normally be the unique key field, but it doesn't have to be.
** it's OK to have a keyField value that can't be found in the index
** it's OK to have some documents without a keyField in the file (defVal is used as the default)
** it's OK for a keyField value to point to multiple documents (no uniqueness requirement)
* valType is a reference to another fieldType to define the value type of this field (must currently be FloatField (float))
The format of the external file is simply
keyFieldValue=floatValue
keyFieldValue=floatValue
Solr looks for the external file in the index directory under the name of
external_<fieldname> or external_<fieldname>.*
If any files of the latter pattern appear, the last (after being sorted by name) will be used and previous versions will be deleted. This is to help support systems where one may not be able to overwrite a file (like Windows, if the file is in use).
If the external file has already been loaded, and it is changed, those changes will not be visible until a commit has been done.
The external file may be sorted or unsorted by the key field, but it will be substantially slower (untested) if it isn't sorted.
was (Author: yseeley@gmail.com):
OK, the latest SOLR-344 patch includes external value source.
Here is what the fieldType in the schema looks like:
<fieldType name="file" class="solr.ExternalFileField" keyField="id" defVal="1" stored="false" indexed="false" valType="float"/>
* keyField will normally be the unique key field, but it doesn't have to be.
** it's OK to have a keyField value that can't be found in the index
** it's OK to have some documents without a keyField in the file (defVal is used as the default)
** it's OK for a keyField value to point to multiple documents (no uniqueness requirement)
* valType is a reference to another fieldType to define the value type of this field (must currently be FloatField (float))
The format of the external file is simply
keyFieldValue=floatValue
keyFieldValue=floatValue
Solr looks for the external file in the index directory under the name of
external_<fieldname> or external_<fieldname>.*
If any files of the latter pattern appear, the last (after being sorted by name) will be used and previous versions will be deleted. This is to help support systems where one may not be able to overwrite a file (like Windows, if the file is in use).
If the external file has already been loaded, and it is changed, those changes will not be visible until a commit has been done.
The external file may be sorted or unsorted by the key field, but it will be substantially slower (untested) if it isn't sorted.
> external value source
> ---------------------
>
> Key: SOLR-351
> URL: https://issues.apache.org/jira/browse/SOLR-351
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
>
> 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.
[jira] Commented: (SOLR-351) external value source
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (SOLR-351) external value source
Posted by "Mike Klaas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Klaas updated SOLR-351:
----------------------------
Fix Version/s: (was: 1.3)
> external value source
> ---------------------
>
> Key: SOLR-351
> URL: https://issues.apache.org/jira/browse/SOLR-351
> Project: Solr
> Issue Type: New Feature
> Components: search
> 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.
[jira] Commented: (SOLR-351) external value source
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531250 ]
Yonik Seeley commented on SOLR-351:
-----------------------------------
Hmmm, due to pluggable query parsers patch, I pass around the QParser everywhere now, so perhaps
it is easiest + consistent to extend that to getValueSource.
public ValueSource getValueSource(SchemaField field, QParser parser)
Easy change... it's only called in one place in the source.
> external value source
> ---------------------
>
> Key: SOLR-351
> URL: https://issues.apache.org/jira/browse/SOLR-351
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
>
> 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.
[jira] Commented: (SOLR-351) external value source
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531200 ]
Hoss Man commented on SOLR-351:
-------------------------------
FieldType is abstract, so we can always add a getValueSource(SolrQueryRequest req, SchemaFIeld field) that delegates to getValueSource(SchemaFIeld field) by default.
(ditto for the init method if needed ... i almost think we should do both since i can imagine situations where FieldType might want to go ahead and pre-compute some info, but doing something like this would raise a lot of questions about what to do when newSearchers are opened ... might be better to stick with the request type access for now untill we have stronger uses cases for anything else)
> external value source
> ---------------------
>
> Key: SOLR-351
> URL: https://issues.apache.org/jira/browse/SOLR-351
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
>
> 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.
[jira] Updated: (SOLR-351) external value source
Posted by "Ryan McKinley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan McKinley updated SOLR-351:
-------------------------------
Component/s: search
Fix Version/s: 1.3
> external value source
> ---------------------
>
> Key: SOLR-351
> URL: https://issues.apache.org/jira/browse/SOLR-351
> Project: Solr
> Issue Type: New Feature
> Components: search
> Reporter: Yonik Seeley
> Fix For: 1.3
>
> 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.
[jira] Commented: (SOLR-351) external value source
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531203 ]
Yonik Seeley commented on SOLR-351:
-----------------------------------
> a lot of questions about what to do when newSearchers are opened
Yeah, it's not actually getValueSource() where one would normally want the request... ValueSource is like a Query - relatively independent of context. getValues(IndexReader reader) is where you normally want it.. but there are layers of Lucene in between that know nothing of Solr.
> external value source
> ---------------------
>
> Key: SOLR-351
> URL: https://issues.apache.org/jira/browse/SOLR-351
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
>
> 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.
[jira] Issue Comment Edited: (SOLR-351) external value source
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531988 ]
yseeley@gmail.com edited comment on SOLR-351 at 10/2/07 7:49 PM:
------------------------------------------------------------
OK, the latest SOLR-344 patch includes external value source.
Here is what the fieldType in the schema looks like:
<fieldType name="file" class="solr.ExternalFileField" keyField="id" defVal="1" stored="false" indexed="false" valType="float"/>
* keyField will normally be the unique key field, but it doesn't have to be.
** it's OK to have a keyField value that can't be found in the index
** it's OK to have some documents without a keyField in the file (defVal is used as the default)
** it's OK for a keyField value to point to multiple documents (no uniqueness requirement)
* valType is a reference to another fieldType to define the value type of this field (must currently be FloatField (float))
The format of the external file is simply
keyFieldValue=floatValue
keyFieldValue=floatValue
Solr looks for the external file in the index directory under the name of
external_<fieldname> or external_<fieldname>.*
If any files of the latter pattern appear, the last (after being sorted by name) will be used and previous versions will be deleted. This is to help support systems where one may not be able to overwrite a file (like Windows, if the file is in use).
If the external file has already been loaded, and it is changed, those changes will not be visible until a commit has been done.
The external file may be sorted or unsorted by the key field, but it will be substantially slower (untested) if it isn't sorted.
was (Author: yseeley@gmail.com):
OK, the latest SOLR-344 patch includes external value source.
Here is what the fieldType in the schema looks like:
<fieldType name="file" class="solr.ExternalFileField" keyField="id" defVal="1" stored="false" indexed="false" valType="float"/>
* keyField will normally be the unique key field, but it doesn't have to be.
** it's OK to have a keyField value that can't be found in the index
** it's OK to have some documents without a keyField in the file (defVal is used as the default)
** it's OK for a keyField value to point to multiple documents (no uniqueness requirement)
* valType is a reference to another fieldType to define the value type of this field (must currently be FloatField (float))
The format of the external file is simply
keyFieldValue=floatValue
keyFieldValue=floatValue
Solr looks for the external file in the index directory under the name of
external_<filename> or external_<filename>.*
If any files of the latter pattern appear, the last (after being sorted by name) will be used and previous versions will be deleted. This is to help support systems where one may not be able to overwrite a file (like Windows, if the file is in use).
If the external file has already been loaded, and it is changed, those changes will not be visible until a commit has been done.
The external file may be sorted or unsorted by the key field, but it will be substantially slower (untested) if it isn't sorted.
> external value source
> ---------------------
>
> Key: SOLR-351
> URL: https://issues.apache.org/jira/browse/SOLR-351
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
>
> 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.
[jira] Commented: (SOLR-351) external value source
Posted by "J.J. Larrea (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (SOLR-351) external value source
Posted by "Yonik Seeley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530820 ]
Yonik Seeley commented on SOLR-351:
-----------------------------------
Obstacle #1: how to find the index directory (we really need the solr core passed at some point - perhaps during FieldType.init()?
It would be nice of a SolrQueryRequest object was passed during all calls to things like getValueSource(), but it may be too late for that (and much more difficult).
> external value source
> ---------------------
>
> Key: SOLR-351
> URL: https://issues.apache.org/jira/browse/SOLR-351
> Project: Solr
> Issue Type: New Feature
> Reporter: Yonik Seeley
>
> 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.