[
https://issues.apache.org/jira/browse/SOLR-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015585#comment-13015585
]
Ryan McKinley commented on SOLR-2444:
-------------------------------------
bq. That seems like more complexity than it's worth, and would really only work
with parameter-less functions (if implemented as a hashmap lookup) since
different arguments to the function would cause the match to fail.
this is why i bring it up, and why I think it *is* the same issue. We need to
agree on what it means. and i'm pretty sure that has consequences on how we
implement the basic parsing.
As you say, i would expect different arguments to the function should not match
a pseudo field.
fl=id,foo(a)
would not use the pseudo field defined in
fl.pseudo.foo(a)=something
I think we only need to say that exact matches would get replaced. For example
fl=id,foo( a )
does not need to match
fl.pseudo.foo(a)=something
We can say that functions/transformers are not supported by pseudo fields --
i'm fine with that, but think we need to be explicit. One argument to support
it is so that you could swap the meaning of some function w/out updating
clients.
bq. "transformer syntax" also seems like an somewhat orthoginal issue
Not really, it is about how we parse the fl.
bq. Has anyone commented on the proposed syntax
nope -- other then hoss agreeing that SQL SELECT 1 is very useful and we should
make it simple
bq. (what is the full proposed syntax anyway? I need to see some examples with
more than one parameter)
The proposed syntax is:
[name] and [name:argument]
For the key use cases I can think of having a single inline parameter is very
useful [value:10], for more complex args, the transformer can use
SolrQueryRequest
bq. Is it important to allow these transformer parameters inline in "fl"? etc.
For me they are equally important to inline functions. I plan to use them for
things that do not map cleanly to functions. A simple example, if you have a
geohash point that encodes X and Y in a single field, i want to return that
with well typed difference between X and Y. With a transformer, i can return
{x:10, y:20} rather then just {point:'10 20'} and make the client figure out if
I mean x y or lat lon.
The other key place I see them getting used is with returning highlighed fields
inline
?fl=id,name,[hl:name]
would return the raw name field and the highlighted name field. All the other
highlight parameters would be fetched from getParams()
> Update fl syntax to support: pseudo fields, AS, transformers, and wildcards
> ---------------------------------------------------------------------------
>
> Key: SOLR-2444
> URL: https://issues.apache.org/jira/browse/SOLR-2444
> Project: Solr
> Issue Type: New Feature
> Reporter: Ryan McKinley
> Attachments: SOLR-2444-fl-parsing.patch, SOLR-2444-fl-parsing.patch
>
>
> The ReturnFields parsing needs to be improved. It should also support
> wildcards
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
