Hi Peter,
in fact I mainly want to search Hotels by any combination of its fields
and its rooms and packages. Users can setup any combination in a dynamic
form that changes after every change of the query.
But maybe the right term for this use case is "filter" not a "search".
The form enables fitering of hotels by predefined set of properties. And
also it allows to specify it with some text search - so probably only in
this case I should use the term "search".
To illustrate it I will describe a simple search (or filter?) form example:
Message: now available 1000 hotels
Select country: combo with countries
Select place: combo with places
Select start date: combo with available dates
Select boarding: combo with available boarding types
Select price: combo with available prices (0-100, 100-200)
Select room size: combo with available bed counts
At first the form is populated by all available values. But when user
selects a country, all other fields are repopulated with values
available only for hotels in the selected country and the label above
the form changes the number of available hotels acording to the search
criteria. Afterwards the user selects a price level and again number of
available hotels changes and the other combo boxes are repopulated with
available values according to selected country and price level.
If I am not wrong, this is the place for Faceting, isn't it?
When the user is done with the search form, he can display the matching
hotels and afterwards continue with displaying matching rooms and
packages in a particular hotel.
In fact I am always looking for a concrete Package (offer, booking) that
matches all the given criteria, but on the search output there is always
only the hotel containing the given Package as well for faceting counts,
no matter whether there is 1 or 50 packages matching the query, the
hotel is counted only once as well as it is listed only once in the results.
The Faceting is the thing I am really interested in becase the described
functionality implemented on top of RDBMS results in multiple SQL
queries joining multiple tables each time a user changes the search
criteria, so the load of DB servers is quite high.
I would like to use Solr for the search form because after some test the
Lucene seams to be really very fast and I believe it would improve the
response time as well as the thruput of our search.
I am new to Solr so excuse me if I don't use the right terminology yet,
but I hope that my description of the use case is quite clear now. ;-)
Thanks
Wenca
Dne 17.8.2010 13:46, Peter Karich napsal(a):
Hi Wenca,
I am not sure wether my information here is really helpful for you,
sorry if not ;-)
I want only hotels that have room with 2 beds and the room has a
package with all inclusive boarding and price lower than 400.
you should tell us what you want to search and filter? Do you want only
available or all beds/rooms of a hotel?
The requirements seems to be a bit tricky but a combination of dynamic
fields and the collapse feature could do it (with only one query).
In your case I would start indexing the hotels like:
name: hilton
country: USA
city: New York
beds_i (multivalued): 2 | 1 | 1 | ...
rooms_i: 123
...
I am not sure how I would handle the booking/prices. Maybe you will have
to add an additional dynamic
field free_beds_periodX_i or price_periodX_i which reports the free beds
or prices for a specific period?
(where one period could be a week or even a day ...)
For the other searches I would create another index although it is
possible to put all the data in one index
and e.g. add a 'type' field to each document. With that field you can
than append a filter query to each query:
q=xy&fq=type:hotel or type:room
I would prefer this trick over the collapse feature (if you really want
to setup only one index) at the beginning
and see if this could work for you. (the collapse feature is not that
mature like the the rest of solr, but in some situations it works nicely.)
Hopes this helps a bit to get started. (Regarding the 'Data Import
Handler' I cannot help, sorry)
Regards,
Peter.
