Chris Hostetter wrote:
: > there is nothing like this in solr right now, it doesn't seem like something
: > that should be odne in solr, as it would be a simple translation that could
: > be done via an XSLT or some client layer code.
: It may be more work then it is worth, but I would like to see something
: comparable to the SQL 'AS' syntax:
:
: &fl=162_sortable_s as SortedField,name,id
:
: This would be good because it solves the problem for non XML based responses
: also.
But regardless of the format, If the client is the one saying "ugly_fieldname
AS pretty_fieldname" then why not let the client do the translation?
In some cases, the client does not -- or should not -- know the full
schema details, and the schema details may change.
I'm using solr as a public web service. While I could put a layer
between solr and the world, it is easier (better documented and supports
JSON/xml/ruby/etc) to expose solr directly and make sure end users
cann't muck stuff up.
I can see having server side configuration to "hide" the real field names
from clients ( http://wiki.apache.org/solr/FieldAliasesAndGlobsInParams )
I just dont' see the benefit in having the client ask the server to do
something the client can do just as easily.
I'm thinking more along the lines of invariant params. The solr admin
defines what fields are available and how they display, the client reads
them.
But i see your point. To me the rationale is close to why SQL has an
'AS' syntax.
If, however, some of then ideas from that FieldAliasesAndGlobsInParams
wiki were implemented, then we probably would need someway to configure
generic fieldname renaming in the response ... if you've got server
configuration that maps pretty_fieldname to ugly_fieldname for the
purposes of sorting you need to ensure that the users can see
pretty_fieldname in the response (hmm, the sort field could probably be
handled as a special case, just like score field). Likewise if you have
server config to translate "fl=pretty1,pretty2,name,nice*" to
"fl=uglyA,uglyB,name,text_*" then you need to make sure the do the reverse
translation when output the stored field values for uglyA, uglyB and the
text_ fields (which could get complicated when dealing with regex based
field mappings ... i guess we could just require the solr admin to
cofigure both regex if they want both the param translation and the
response translation)
i can see it opens a can of worms. This isn't something I'm going to
tackle anytime soon....
ryan
