lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2444) Update fl syntax to support: pseudo fields, AS, transformers, and wildcards
Date Sun, 03 Apr 2011 20:10:05 GMT

    [ https://issues.apache.org/jira/browse/SOLR-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015202#comment-13015202
] 

Hoss Man commented on SOLR-2444:
--------------------------------


I'm not particularly a fan of the specific syntax "x AS y", but i'm not opposed to it -- although
your specific example (with a number on the right side) confuses me ... i think you must have
actually ment something like this, correct? ...
{code}
?fl=id,[value:10] as hard_coded_price
{code}

The one change i'd like argue in favor of is ensuring we have *some* way to deal with fieldnames
that are esoteric. ie: containing whitespaces or special characters

I don't think we need stress out about a lot of quoting/escaping in the common case -- the
rules used in the FunctionQParser to identify "simple" field names should be good enough for
most people, and helps keep the syntax clean for the majority of users who have straight forward
field names, but it would definitely be nice if there was some way for people to refer to
complex field names (either as "input" (for referring to esoteric field names in their documents)
or as "output" (for generating esoteric field names as the result of an alias/transformation)

I think the two changes to what Ryan has already described that might make this totally feasible
would be...

1) a quote character discovered where fields like fl expect to encounter a field name (like
"fl") should trigger quoted terminated string parsing (where white space and punctuation are
considered part of hte string, and backslash can be used escapes quotes) and the reuslting
string will be used as the field name.

2) the psuedo field param mapping ryan described should move the fieldname to the "key" so
there is no ambiguity if the seperator appears twice, ie... 

{code}
?hl.pseudo.xxx%3Ayyy=zzz
   ..instead of...
?hl.pseudo=xxx%3Ayyy%3Azzz
{code}


If we did those two things, then these would all be equivilent...

{code}
?fl=id,price&fl.pseudo.price=real_price_field
?fl=id,real_price_field+AS+price
?fl=id,"real_price_field"+AS+"price"
{code}

...but it would also be possible to have either of these...

{code}
?fl=id,"external+price+alias"&fl.pseudo.external+price+alias=internal+price+field
?fl=id,"internal+price+field"+AS+"external+price+alias"
{code}

...this shouldn't cause a problem with the syntax for echoing back literal values, since that
would already require a transformer...

{code}
?fl=id,[value:"No+it+is+Not"]+AS+"Is+Product+In+Stock"
(all products temporarily out of stock)
{code}


> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message