You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Naimdjon Takhirov <tn...@yahoo.com> on 2005/07/01 08:57:13 UTC
Vedr. Re: Design question [too many fields?]
Hi Chris,
It is anyway going to be too many fields then? Days of
year for the whole year ahead? Since the fromDate and
toDate can be across two months and the customer wants
the data be available for one year.
Naimdjon
--- Chris Lu <ch...@gmail.com> skrev:
> Mark, your suggestion will incur another trip to the
> database. And if
> the search results is large, filtering in DB by pk
> is not really good.
>
> Erik, your original "date" field is good when there
> is not many
> dates(<1024) in the database. Otherwise, Range Query
> can not handle it.
>
> My suggestion is, use "year" + "month" + "day" three
> fields to store
> date. And when searching, for example, any date
> that's greater than
> 2005-06-30, you can use this query to search: ( year
> > 2005 ) or (
> year=2005 and month>=6) or ( year=2005 and month=6
> and day > 30 ).
> It's a combination of BooleanQuery, TermQuery, and
> RangeQuery.
>
> This may seem cumbersome, but it can save one trip
> to database, and
> circumvent Lucene's limitation.
>
> Chris Lu
> http://www.dbsight.net
>
> Erik Hatcher wrote:
>
> > I second Mark's suggestion over the alternative I
> posted. My
> > alternative was merely to invert the field
> structure originally
> > described, but using a Filter for the volatile
> information is wiser.
> >
> > Erik
> >
> > On Jun 29, 2005, at 9:58 AM, mark harwood wrote:
> >
> >> Presumably there is also a free-text element to
> the
> >> search or you wouldn't be using Lucene.
> >>
> >> Multiple fields is not the way to go.
> >> A single Lucene field could contain multiple
> terms (
> >> the available dates) but I still don't think
> that's
> >> the best solution.
> >> The availability info is likely to be pretty
> volatile
> >> and you always want up-to-date info so I would
> prefer
> >> to hit a database for this. If you keep a DB
> primary
> >> key to Lucene doc id look-up cached in memory you
> can
> >> quickly construct a Lucene filter from the
> database
> >> results and therefore only show Lucene results
> for
> >> available rooms.
> >>
> >> Cheers
> >> Mark
> >>
> >>
> >>
> >>
>
___________________________________________________________
> >> How much free photo storage do you get? Store
> your holiday
> >> snaps for FREE with Yahoo! Photos
> http://uk.photos.yahoo.com
> >>
> >>
>
---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> java-user-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail:
> java-user-help@lucene.apache.org
> >>
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail:
> java-user-help@lucene.apache.org
> >
> >
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail:
> java-user-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Re: Vedr. Re: Design question [too many fields?]
Posted by Chris Lu <ch...@gmail.com>.
> It is anyway going to be too many fields then? Days of
> year for the whole year ahead? Since the fromDate and
> toDate can be across two months and the customer wants
> the data be available for one year.
It won't have too many fields.
> > My suggestion is, use "year" + "month" + "day" three
> > fields to store
"day" field means days for one month. So "month" and "day" two fields
will have 12 and 31 values respectively.
And "year" field depends on what data you got. I guess your data won't
span accross 1024 years.
--
Chris Lu
---------------------
Full-Text Search on Any Database
http://www.dbsight.net
On 6/30/05, Naimdjon Takhirov <tn...@yahoo.com> wrote:
> Hi Chris,
>
> It is anyway going to be too many fields then? Days of
> year for the whole year ahead? Since the fromDate and
> toDate can be across two months and the customer wants
> the data be available for one year.
>
> Naimdjon
>
> --- Chris Lu <ch...@gmail.com> skrev:
>
> > Mark, your suggestion will incur another trip to the
> > database. And if
> > the search results is large, filtering in DB by pk
> > is not really good.
> >
> > Erik, your original "date" field is good when there
> > is not many
> > dates(<1024) in the database. Otherwise, Range Query
> > can not handle it.
> >
> > My suggestion is, use "year" + "month" + "day" three
> > fields to store
> > date. And when searching, for example, any date
> > that's greater than
> > 2005-06-30, you can use this query to search: ( year
> > > 2005 ) or (
> > year=2005 and month>=6) or ( year=2005 and month=6
> > and day > 30 ).
> > It's a combination of BooleanQuery, TermQuery, and
> > RangeQuery.
> >
> > This may seem cumbersome, but it can save one trip
> > to database, and
> > circumvent Lucene's limitation.
> >
> > Chris Lu
> > http://www.dbsight.net
> >
> > Erik Hatcher wrote:
> >
> > > I second Mark's suggestion over the alternative I
> > posted. My
> > > alternative was merely to invert the field
> > structure originally
> > > described, but using a Filter for the volatile
> > information is wiser.
> > >
> > > Erik
> > >
> > > On Jun 29, 2005, at 9:58 AM, mark harwood wrote:
> > >
> > >> Presumably there is also a free-text element to
> > the
> > >> search or you wouldn't be using Lucene.
> > >>
> > >> Multiple fields is not the way to go.
> > >> A single Lucene field could contain multiple
> > terms (
> > >> the available dates) but I still don't think
> > that's
> > >> the best solution.
> > >> The availability info is likely to be pretty
> > volatile
> > >> and you always want up-to-date info so I would
> > prefer
> > >> to hit a database for this. If you keep a DB
> > primary
> > >> key to Lucene doc id look-up cached in memory you
> > can
> > >> quickly construct a Lucene filter from the
> > database
> > >> results and therefore only show Lucene results
> > for
> > >> available rooms.
> > >>
> > >> Cheers
> > >> Mark
> > >>
> > >>
> > >>
> > >>
> >
> ___________________________________________________________
> > >> How much free photo storage do you get? Store
> > your holiday
> > >> snaps for FREE with Yahoo! Photos
> > http://uk.photos.yahoo.com
> > >>
> > >>
> >
> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail:
> > java-user-unsubscribe@lucene.apache.org
> > >> For additional commands, e-mail:
> > java-user-help@lucene.apache.org
> > >>
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > java-user-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail:
> > java-user-help@lucene.apache.org
> > >
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail:
> > java-user-help@lucene.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org