[
https://issues.apache.org/jira/browse/SOLR-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789898#action_12789898
]
Yonik Seeley commented on SOLR-1298:
------------------------------------
A few comments and random thoughts on this feature in general:
- Think scalability... there should be a way to keep things streamable. Some
people will want to retrieve values for many documents (10K, 100K, or their
whole index). But of course there should be a way for a component to simply
add values calculated all at once too.
- For performance, providers of field values should be able to operate on
multiple documents at once. For example, providers may want to sort big blocks
of docids and access in docid order for better performance (important for
anything that accesses the index). A value provider that needs to access
another system would want to send multiple IDs in a batch.
- Field value providers should be given context, including optionally the set
of fields for the current document, and probably the request and response
objects
- Perhaps this should be more generalized in that the value provider be a
document mutator - it should be able to also change or remove other fields. I
believe this would also allow stuff like per-field security. Field value
providers should also be able to add multiple fields - it may not know ahead of
time what extra fields a document has.
- should work with highlighting... this way people don't have to store large
text fields if they already have them in another system.
- keep in mind that some people believe that derived fields (or meta fields)
don't belong in the same place as other stored fields. I think it probably
depends on the exact usecase though.
- I'm not sure if SolrIndexSearcher is the right place for this or not though -
perhaps its document() method should stick to just the stored fields?
- Think about how to name these fields nicer names... perhaps this could even
include the "select as" ability to rename fields.
One thought: use an optional '=' or use the "AS" syntax
fl=foo=bar,dist=gdist(10,20,loc) or
fl=foo AS bar, gdist(10,20,loc) AS dist (more familiar to DB people?)
Another option for providing names that would only work with queries/function
queries would be local params:
fl={!key=dist}gdist(10,20,loc)
but that only works for queries so it's not as flexible
- *If* we use the fl syntax for including function queries, then we should
consider providing the ability to use multiple "fl" params. This will make it
easier for clients who want to tack something on w/o modifying other params.
If we provide multiple fl params, then an alternate way to specify aliases
could be:
fl.dist=gdist(10,20,loc)
- fl=foo is ambiguous... do we mean a function query or the field?... perhaps
if it's a bare field name, then we treat it as a field unless it has
localparams?
fl={!func}foo
> FunctionQuery results as pseudo-fields
> --------------------------------------
>
> Key: SOLR-1298
> URL: https://issues.apache.org/jira/browse/SOLR-1298
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1298-FieldValues.patch, SOLR-1298.patch
>
>
> It would be helpful if the results of FunctionQueries could be added as
> fields to a document.
> Couple of options here:
> 1. Run FunctionQuery as part of relevance score and add that piece to the
> document
> 2. Run the function (not really a query) during Document/Field retrieval
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
