zaadjis, I definitely don't have a better solution, but one issue is how bucket ranges might need to be defined run time, i.e. if the result set is 50 products and all are under $100, it might make sense to have buckets of 0-$20, $20-$50, $50-$100, but if those same products are evenly distributed over a 0-$1000 range, having 3 buckets under $100 would seem less intuitive to a user. I'm going to tinker with this for a bit.... Thanks for the input guys!
On Jul 30, 9:03 am, Pat Allan <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
