I oversimplified my question somewhat. The realprice can actually be 1 out +/- 10 thousand dynamic fields. Which one is determined at query time. (price depends on date, class, and some other properties. The product of the options of these properties amount to the 10k number ) The avg field follows a similar pattern: it's actually 1 out of +/- 10 dynamic fields. So populating a field at index-time sadly is out of the question.
would a custom fieldtype (with possibly a custom valuesource that determines from which index: realprice or avgprice to actually take the value) be a possibility here? I'm looking for a way that would work transparently even if used for faceting or filtering. Would that be the case in this scenario? Sorting is a special case as well since that independent of what sort is used: products with realprices should always come prior to products with only avg-prices. Thanks, Geert-Jan ryantxu wrote: > > can you just add a new field that has the real or ave price? > Just populate that field at index time... make it indexed but not > stored > > If you want the real or average price to be treated the same in > faceting, you are really going to want them in the same field. > > > On Aug 28, 2009, at 1:16 PM, Britske wrote: > >> >> I have 2 fields: >> realprice >> avgprice >> >> I'd like to be able to take the contents of avgprice if realprice is >> not >> available. >> due to design the average price cannot be encoded in the 'realprice'- >> field. >> >> Since I need to be able to filter, sort and facet on these fields, >> it would >> be really nice to be able to do that just on something like a >> virtual-field >> called 'price' or something. That field should contain the >> conditional logic >> to know from which actual field to take the contents from. >> >> I was looking at using functionqueries, but to me knowledge these >> can't be >> used to filter and facet on. >> >> Would creating a custom field work for this or does a field know >> nothing >> from its sibling-fields? What would performance impact be like, >> since this >> is really important in this instance. >> >> Any better ways? Subclassing standardrequestHandler and hacking it all >> together seems rather ugly to me, but if it's needed... >> >> Thanks, >> Geert-Jan >> >> -- >> View this message in context: >> http://www.nabble.com/If-field-A-is-empty-take-field-B.-Functionality-available--tp25193668p25193668.html >> Sent from the Solr - User mailing list archive at Nabble.com. >> > > > -- View this message in context: http://www.nabble.com/If-field-A-is-empty-take-field-B.-Functionality-available--tp25193668p25195628.html Sent from the Solr - User mailing list archive at Nabble.com.
