You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by lee carroll <le...@googlemail.com> on 2010/12/01 10:55:17 UTC
schema design for related fields
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
Re: schema design for related fields
Posted by Geert-Jan Brits <gb...@gmail.com>.
"if first is selected in the user interface and we have 10 price ranges
query would be 120 cluases (12 months * 10 price ranges)"
What would you intend to do with the returned facet-results in this
situation? I doubt you want to display 12 categories (1 for each month) ?
When a user hasn't selected a date, perhaps it would be more useful to show
the cheapest fare regardless of month and facet on that?
This would involve introducing 2 new fields:
FareDateDontCareStandard, FareDateDontCareFirst
Populate these fields on indexing time, by calculating the cheapest fares
over all months.
This then results in every query having to support at most 20 price ranges
(10 for normal and 10 for first class)
HTH,
Geert-Jan
2010/12/1 lee carroll <le...@googlemail.com>
> 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 <er...@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.carroll@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
> > >
> >
>
Re: schema design for related fields
Posted by Geert-Jan Brits <gb...@gmail.com>.
Indeed, selecting the best price for January OR April OR November and
sorting on it isn't possible with this solution (if that's what you mean).
However, any combination of selecting 1 month and/or 1 price-range and/or 1
fare-type IS possible.
2010/12/1 lee carroll <le...@googlemail.com>
> Hi Geert,
>
> Ok I think I follow. the magic is in the multi-valued field.
>
> The only danger would be complexity if we allow users to multi select
> months/prices/fare classes. For example they can search for first prices in
> jan, april and november. I think what you describe is possible in this case
> just complicated. I'll see if i can hack some facets into the proto type
> tommorrow. Thanks for your help
>
> Lee C
>
> On 1 December 2010 17:57, Geert-Jan Brits <gb...@gmail.com> wrote:
>
> > 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 <le...@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 <le...@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 <er...@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
> > > >> <le...@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 <erickerickson@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.carroll@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
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: schema design for related fields
Posted by lee carroll <le...@googlemail.com>.
Hi Geert,
Ok I think I follow. the magic is in the multi-valued field.
The only danger would be complexity if we allow users to multi select
months/prices/fare classes. For example they can search for first prices in
jan, april and november. I think what you describe is possible in this case
just complicated. I'll see if i can hack some facets into the proto type
tommorrow. Thanks for your help
Lee C
On 1 December 2010 17:57, Geert-Jan Brits <gb...@gmail.com> wrote:
> 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 <le...@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 <le...@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 <er...@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
> > >> <le...@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 <er...@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.carroll@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
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: schema design for related fields
Posted by Geert-Jan Brits <gb...@gmail.com>.
Also, filtering and sorting on price can be done as well. Just be sure to
use the correct price- field.
Geert-Jan
2010/12/1 Geert-Jan Brits <gb...@gmail.com>
> 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 <le...@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 <le...@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 <er...@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
>> >> <le...@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 <er...@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.carroll@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
>> >> > > >
>> >> > >
>> >> >
>> >>
>> >
>> >
>>
>
>
Re: schema design for related fields
Posted by Geert-Jan Brits <gb...@gmail.com>.
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 <le...@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 <le...@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 <er...@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
> >> <le...@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 <er...@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.carroll@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
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: schema design for related fields
Posted by lee carroll <le...@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 <le...@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 <er...@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
>> <le...@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 <er...@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.carroll@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
>> > > >
>> > >
>> >
>>
>
>
Re: schema design for related fields
Posted by lee carroll <le...@googlemail.com>.
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 <er...@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
> <le...@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 <er...@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.carroll@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
> > > >
> > >
> >
>
Re: schema design for related fields
Posted by Erick Erickson <er...@gmail.com>.
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
<le...@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 <er...@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.carroll@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
> > >
> >
>
Re: schema design for related fields
Posted by lee carroll <le...@googlemail.com>.
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 <er...@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.carroll@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
> >
>
Re: schema design for related fields
Posted by Erick Erickson <er...@gmail.com>.
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 <le...@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
>