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