> > Do we attempt to raise some sort of functional query to find the least > amount of the requested price id's? This would seem to imply some playing > around in the query handler to allow a function of this sort. > Unless I am missing something, this information can always be obtained by post-processing the data obtained from search results. Isn't it?
Do we look at this rather than some internal method to handle the query > and sort actions as a matter of relevancy on a calculated field? If so the > methods of determining the fields included in the calculated field are > alluding me at the moment. So pointers are welcome. > I really did not understand the question. Is it related to "sorting" of results? Does this ultimately involve the implementation of some sort of custom > type and handler to do this sort of task. > If the answer to my previous question is affirmative, then yes, you would need to implement custom sorting behavior. It can be achieved in multiple ways depending upon your requirement. From something as simple as function-queries to using the power of dynamic fields to writing a custom field-type to writing a custom implementation of Lucene's Similarity .. any of these can be a potential answer to custom sorting. Cheers Avlesh On Wed, Oct 14, 2009 at 5:53 PM, Neil Lunn <neil.l...@trixan.com> wrote: > We have come up against a situation we are trying to resolve in our Solr > implementation project. This revolves mostly around how to sort results > from > index data we are likely to store in multiple fields but at runtime we are > likely to query on the result of which one is most relevant. A brief > example: > We have product catalog information in the index which will have multiple > prices dependent on the user logged in and other scenarios. For > simplification this will look something like this: > > price_id101 = 100.00 > price_id102 = 105.00 > price_id103 = 110.00 > price_id104 = 95.00 > (etc) > > What we are looking at is at runtime we want to know which one of several > selected prices is the minimum (or maximum), but not all prices, just a > select set of say 3 or 2 id's. The purpose we are looking at is to > determine > a sort order to the results. This as we would be aware approaching a SQL > respository we would feed it some query logic to say "find me the least > amount of these set of id's", therefore the search approach here raises > some > questions. > > - Do we attempt to raise some sort of functional query to find the least > amount of the requested price id's? This would seem to imply some playing > around in the query handler to allow a function of this sort. > > - Do we look at this rather than some internal method to handle the query > and sort actions as a matter of relevancy on a calculated field? If so the > methods of determining the fields included in the calculated field are > alluding me at the moment. So pointers are welcome. > > - Does this ultimately involve the implementation of some sort of custom > type and handler to do this sort of task. > > I am open to any response as if someone has not come across a similar > problem before and can suggest an approach we are willing to open up a > patch > branch or similar to do some work on the issue. Though if there are no > suggestions this will likely move out of our current stream and into future > development. > > Neil >
