Ok longer answer than anticipated (and good conceptual practice ;-) Yeah I belief that would work if I understand correctly that:
'in Jan [9] in feb [10] in march [1]' has nothing to do with pricing, but only with availability? If so you could seperate it out as two seperate issues: 1. ) showing pricing (based on context) 2. ) showing availabilities (based on context) For 1.) you get 39 pricefields ([jan,feb,..,dec,dc] * [standard,first,dc]) note: 'dc' indicates 'don't care. depending on the context you query the correct pricefield to populate the price facet-values. for discussion lets call the fields: _p[fare][date]. IN other words the price field for no preference at all would become: _pdcdc For 2.) define a multivalued field 'FaresPerDate 'which indicate availability, which is used to display: A) Standard fares [10] First fares [3] B) in Jan [9] in feb [10] in march [1] A) depends on your selection (or dont caring) about a month B) vice versa depends on your selection (or dont caring) about a fare type given all possible date values: [jan,feb,..dec,dontcare] given all possible fare values:[standard,first,dontcare] FaresPerDate consists of multiple values per document where each value indicates the availability of a combination of 'fare' and 'date': (standardJan,firstJan,DCjan...,standardJan,firstDec,DCdec,standardDC,firstDC,DCDC) Note that the nr of possible values = 39. Example: 1. ) the user hasn't selected any preference: q=*:*&facet.field:FaresPerDate&facet.query=_pdcdc:[0 TO 20]&facet.query=_pdcdc:[20 TO 40], etc. in the client you have to make sure to select the correct values of 'FaresPerDate' for display: in this case: Standard fares [10] --> FaresPerDate.standardDC First fares [3] --> FaresPerDate.firstDC in Jan [9] -> FaresPerDate.DCJan in feb [10] -> FaresPerDate.DCFeb in march [1]-> FaresPerDate.DCMarch 2) the user has selected January q=*:*&facet.field:FaresPerDate&fq=FaresPerDate:DCJan&facet.query=_pDCJan:[0 TO 20]&facet.query=_pDCJan:[20 TO 40] Standard fares [10] --> FaresPerDate.standardJan First fares [3] --> FaresPerDate.firstJan in Jan [9] -> FaresPerDate.DCJan in feb [10] -> FaresPerDate.DCFeb in march [1]-> FaresPerDate.DCMarch Hope that helps, Geert-Jan 2010/12/1 lee carroll <lee.a.carr...@googlemail.com> > Sorry Geert missed of the price value bit from the user interface so we'd > display > > Facet price > Standard fares [10] > First fares [3] > > When traveling > in Jan [9] > in feb [10] > in march [1] > > Fare Price > 0 - 25 : [20] > 25 - 50: [10] > 50 - 100 [2] > > cheers lee c > > > On 1 December 2010 17:00, lee carroll <lee.a.carr...@googlemail.com> > wrote: > > > Geert > > > > The UI would be something like: > > user selections > > for the facet price > > max price: £100 > > fare class: any > > > > city attributes facet > > cityattribute1 etc: xxx > > > > results displayed something like > > > > Facet price > > Standard fares [10] > > First fares [3] > > in Jan [9] > > in feb [10] > > in march [1] > > etc > > is this compatible with your approach ? > > > > Erick the price is an interval scale ie a fare can be any value (not > high, > > low, medium etc) > > > > How sensible would the following approach be > > index city docs with fields only related to the city unique key > > in the same index also index fare docs which would be something like: > > Fare: > > cityID: xxx > > Fareclass:standard > > FareMonth: Jan > > FarePrice: 100 > > > > the query would be something like: > > q=FarePrice:[* TO 100] FareMonth:Jan fl=cityID > > returning facets for FareClass and FareMonth. hold on this will not facet > > city docs correctly. sorry thasts not going to work..... > > > > > > > > > > > > > > > > > > On 1 December 2010 16:25, Erick Erickson <erickerick...@gmail.com> > wrote: > > > >> Hmmm, that's getting to be a pretty clunky query sure enough. Now you're > >> going to > >> have to insure that HTTP request that long get through and stuff like > >> that.... > >> > >> I'm reaching a bit here, but you can facet on a tokenized field. > Although > >> that's not > >> often done there's no prohibition against it. > >> > >> So, what if you had just one field for each city that contained some > >> abstract > >> information about your fares etc. Something like > >> janstdfareclass1 jancheapfareclass3 febstdfareclass6.... > >> > >> Now just facet on that field? Not #values# in that field, just the field > >> itself. You'd then have to make those into human-readable text, but that > >> would considerably simplify your query. Probably only works if your user > >> is > >> selecting from pre-defined ranges, if they expect to put in arbitrary > >> ranges > >> this scheme probably wouldn't work... > >> > >> Best > >> Erick > >> > >> On Wed, Dec 1, 2010 at 10:22 AM, lee carroll > >> <lee.a.carr...@googlemail.com>wrote: > >> > >> > Hi Erick, > >> > so if i understand you we could do something like: > >> > > >> > if Jan is selected in the user interface and we have 10 price ranges > >> > > >> > query would be 20 cluases in the query (10 * 2 fare clases) > >> > > >> > if first is selected in the user interface and we have 10 price ranges > >> > query would be 120 cluases (12 months * 10 price ranges) > >> > > >> > if first and jan selected with 10 price ranges > >> > query would be 10 cluases > >> > > >> > if we required facets to be returned for all price combinations we'd > >> need > >> > to > >> > supply > >> > 240 cluases > >> > > >> > the user interface would also need to collate the individual fields > into > >> > meaningful aggragates for the user (ie numbers by month, numbers by > fare > >> > class) > >> > > >> > have I understood or missed the point (i usually have) > >> > > >> > > >> > > >> > > >> > On 1 December 2010 15:00, Erick Erickson <erickerick...@gmail.com> > >> wrote: > >> > > >> > > I'd think that facet.query would work for you, something like: > >> > > &facet=true&facet.query=FareJanStandard:[price1 TO > >> > > price2]&facet.query:fareJanStandard[price2 TO price3] > >> > > You can string as many facet.query clauses as you want, across as > many > >> > > fields as you want, they're all > >> > > independent and will get their own sections in the response. > >> > > > >> > > Best > >> > > Erick > >> > > > >> > > On Wed, Dec 1, 2010 at 4:55 AM, lee carroll < > >> > lee.a.carr...@googlemail.com > >> > > >wrote: > >> > > > >> > > > Hi > >> > > > > >> > > > I've built a schema for a proof of concept and it is all working > >> fairly > >> > > > fine, niave maybe but fine. > >> > > > However I think we might run into trouble in the future if we ever > >> use > >> > > > facets. > >> > > > > >> > > > The data models train destination city routes from a origin city: > >> > > > Doc:City > >> > > > Name: cityname [uniq key] > >> > > > CityType: city type values [nine possible values so good for > >> > faceting] > >> > > > ... [other city attricbutes which relate directy to the doc > >> unique > >> > > key] > >> > > > all have limited vocab so good for faceting > >> > > > FareJanStandard:cheapest standard fare in january(float value) > >> > > > FareJanFirst:cheapest first class fare in january(float value) > >> > > > FareFebStandard:cheapest standard fare in feb(float value) > >> > > > FareFebFirst:cheapest first fare in feb(float value) > >> > > > ..... etc > >> > > > > >> > > > The question is how would i best facet fare price? The desire is > to > >> > > return > >> > > > > >> > > > number of citys with jan prices in a set of ranges > >> > > > etc > >> > > > number of citys with first prices in a set of ranges > >> > > > etc > >> > > > > >> > > > install is 1.4.1 running in weblogic > >> > > > > >> > > > Any ideas ? > >> > > > > >> > > > > >> > > > > >> > > > Lee C > >> > > > > >> > > > >> > > >> > > > > >
