lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan McKinley (JIRA)" <>
Subject [jira] [Commented] (SOLR-2444) Update fl syntax to support: pseudo fields, AS, transformers, and wildcards
Date Mon, 04 Apr 2011 19:53:06 GMT


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.
would not use the pseudo field defined in

I think we only need to say that exact matches would get replaced.  For example
fl=id,foo( a )
does not need to match

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

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


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:
>             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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message