Hi Jian, Thanks for your inputs. The (DB) datamodel is quite complex with rooms and room units (I skipped it to make the case easier to understand), so I guess the easiest and actually best way to do it is with the filter.
Mark: yes, there are a lot of text fields the user should be able to search amoung other fields(like facilities etc.). The final question here: Should I use the QueryFilter with query which contains roomId's and filter documents by that those roomId's that are available(for the selected dates)? Or create a filter which extends the Filter class and returns Bits of documents to be searched, in this case the filtering should be done manually document by document. Not sure which solution would show best performance? What do you guys think? Anyways, I am thankfull to Mark, Erik and Jian for inputs. Naimdjon --- jian chen <[EMAIL PROTECTED]> skrev: > Hi, Naimdjon, > > I have some suggestions as well along the lines of > Mark Harwood. > > As an example, suppose for each hotel room there is > a description, and > you want the user to do free text search on the > description field. > You could do the following: > > 1) store hotel room reservation info as rows in a > relational database > create table reservation ( > id int, > room_no int, > reservation_start_date timestamp, > reservation_end_date timestamp, > primary key (id) > ) > > 2) store description for each hotel room in Lucene > index with two > fields, i.e., room_no, description > > 3) provide the user with free text search in room > description as well > as availability info like the following: > --do full text search on description using the > Lucene index > --get the room numbers from the search result > documents > --using these room numbers, look up in the > reservation table to see if > the user specified start date and end date is not > already reserved. > --The top serveral rooms that are high on the free > text search result > and also not reserved will be returned to the user > > How does this sound? > > Jian > > On 6/29/05, Erik Hatcher > <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
