This sounds like the best approach to me - you could either split the 'magic' values into both Ruby code as constants and a custom SQL function, or just do it all in Ruby, but that means your attribute definition is going to be messier (ie: a Case statement instead of a single function call).
-- Pat On 30/07/2009, at 12:40 PM, zaadjis wrote: > > Since I also need to implement such a feature (price buckets), here's > my braindump: > > For the sake of example, let's pretend we have products only from one > category (price buckets would be category specific). > > 1. Have a price bucket be identified with some number, e.g. 0..100 => > 1, 101..200 => 2, etc. This could be a lookup table or be calculated > each time knowing price_min, price_delta (range size), price_max > > 2. Have a magic function that determines the bucket number. Again we > could join with the lookup table or calculate on the go. > > 3. Add the bucket number as an attribute, e.g. has "MAGIC(price)", :as > => :bucket_id, :facet => true > > 4. We would also need the MAGIC function implemented in ruby, so we > can translate user params min_price, max_price into bucket_id > > Anything missing? > > On Jul 29, 8:51 pm, Jay Zeschin <[email protected]> wrote: >> We did this on a project I worked on recently, and ended up using a >> combination of auto-populated fields and SQL case statements to do >> it. For >> fields that we wanted to use as facets, we stored the text string >> in a >> separate column using a before_save callback then had TS index that >> field. >> For other attributes, we used SQL CASE statements in the attribute >> or field >> declarations. >> An example of the latter would be something like: >> >> define_index do >> indexes "CASE WHEN is_new = 1 THEN 'new' ELSE 'used preowned' >> END", :as => >> 'vehicle_status_text' >> end >> >> Obviously you could extend the same logic to determine buckets for >> pricing. >> Not exactly the most elegant solution, but it works reasonably >> well. The >> case statements slow down indexing a little bit, but even with a >> dozen >> CASE-using fields in a set 50,000 records it runs a reindex in a few >> seconds. >> >> On Wed, Jul 29, 2009 at 11:34 AM, Alan <[email protected]> wrote: >> >>> Does anyone have any insight into how to break down a set of items >>> (that have prices) into ranged groups, i.e. >> >>> < $20(5) >>> $20-$50(3) >>> $50-$100(6) >>>> $100(3) >>> . It seems to me that there needs to be a function that somewhat >>> distributes items into the different "buckets" but also have some >>> business logic that makes sure the "buckets" make sense, so you >>> don't >>> get something like: >>> < $19(4) >>> $19-$55(4) >>> $55-$84(5) >>>> $84(4) >> >>> Does anyone have ideas on how this type of thing is done? > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Thinking Sphinx" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/thinking-sphinx?hl=en -~----------~----~----~----~------~----~------~--~---
