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
