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.
"transformer syntax" also seems like an somewhat orthoginal issue
Not really, it is about how we parse the fl.
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
(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
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
rather then just
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()