Brian,
I think most people would just manipulate the data prior to sending it to Solr
for indexing.... but you don't want that.
Your composeField proposal looks fine to me - I can't think of a problem there.
It sounds like you are asking about the language/syntax for field
specification. Could/should you not use the ${fifi} syntax? We already use
that in solrconfig.xml, for example.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
----- Original Message ----
> From: Brian Johnson <[EMAIL PROTECTED]>
> To: solr-user@lucene.apache.org
> Sent: Tuesday, May 6, 2008 2:53:13 PM
> Subject: Composition of multiple smaller fields into another larger field?
>
> I am interested in using the suggest feature against a composition of other
> more
> granular facets. Let me provide an example to help explain my problem and
> proposed approaches.
>
> Say I have a set of facets for these artifacts:
>
>
>
>
> So far things work OK. Now I want my suggest feature to work on a composition
> equivalent to
>
> {city}, {state} {zipcode}
>
> I have these fields defined per the suggestions on adding suggest
> capabilities.
> I'm experimenting so I am trying both options.
>
>
>
> stored="true"/>
>
> I would like to 'compose' the value for these 2 suggest fields based on the
> existing 'atomic' fields. The copyField feature doesn't get me the whole way
> there but I am interested in a similar mechanism.
>
> 1) Is there an existing feature, approach, mechanism, ... to get this done
> that
> I'm just not aware of?
>
> 2) Assuming that #1 is 'no', then would this be a generally useful feature to
> add in? If so how would people like this to be done?
>
> Obviously I can push this down into the document preparation myself outside
> of
> Solr. I would prefer to have a mechanism to handle this in the schema.xml
> since
> I don't want to do any real manipulation/transformation of the data elements
> at
> this point. Here was an initial thought on what it might look like...
>
> Here source is formatted similar to
> java.text.MessageFormat but with named rather than indexed
> substitutions so that.
>
>
> Here source is formatted similar to Velocity templates.
>
>
> I am not interested in creating a new template language or pulling in a new
> dependency to get this done though (velocity, freemarker, ...) per se. I just
> want to do some simple composition. If folks think this is a good idea
> though,
> it could be setup like this instead.
>
>
> class="solr.VelocityTemplateFactory" />
>
> template_filename.vm file contains the following line
> $city, $state $zipcode
>
> Any feedback would be appreciated.
>
> Thanks,
>
> Brian
