Thanks for your answers,
Yes, its true that with boolen queries things are much easier...
+(query1) +(query2) should do an and
or
(query1) (query2) should do an or
and this does not need a special ability to parse the queries
I like the dismax approach, I think is interesting but then to
merge queries is a bit difficult, and I think for this option is better
to try the filter, but then there is no OR option, only , AND. And bq
(from what I understand from de docs) seems that also performs and AND
It's a pity I have to do it for a demo in a few days (and nights) and
I don't think the resulting code will be nice enough to be shown.
Joan
Chris Hostetter wrote:
: To do so I need to store the results as a filter, with a given name, so
: the user can use it later on. But I need to store this in disk, as I can
: not trust on the cache or the web session.
: The user should then indicate that the query that is doing now has a
: filter (a previous query) and this filter should be added to the query
: (this is allowed in solr, i think) but as filter_ID, to be loaded to
: solve the query.
if you really want to be ableto refer to these previous searches using
some sort of identifier, and have them persist for an indefinite amount of
time, it's really out of Solr's hands -- if someone were to try and add a
fewture like this to Solr, how would it know which queries to remember and
generate names for? how long would it store each name? ... these are the
kidns of questsions that your app can understand more easily ... you could
concievable use Solr to store the name=querystring mappings in little
custom solr docs if you wanted, but you have to decide when to create
those mappings and when to expire them.
in general though, all you really need to remember is hte query string,
remembering all of the results really isn't neccessary. The next time
your user wants to "refine" his search -- wether it's 10 seconds latter or
10 days later -- just take the old query string and combine it with the
new query string. how you combine it depends on how you want the scoring
to work, use an "fq" param if the old query shouldn't affect the score,
just define the super set of docs, use a BooleanQuery if you want all the
clauses from both searches to impact the score.
it's important to understand that trying to keep track of the actual
results would be very, very, very bad (especially if you want remember
them for a really long time) because when the user comes back, the index
may have chagned, docs may have shifted ids, or been edited so they no
longer match the criteria, or have been deleted completely.
-Hoss
--
signUPF
Joan Codina
Filb
Departament de Tecnologia
Universitat Pompeu Fabra
___
Abans d'imprimir aquest e-mail, pensa si realment
s necessari, i en
cas de que ho sigui, pensa que si ho fas a doble cara estalvies un 25%
del paper, els arbres t'ho agrairan.
___
La informaci
d'aquest missatge electrnic s confidencial,
personal i intransferible
i noms est dirigida a la/les
adrea/ces indicades a dalt. Si vost
llegeix aquest missatge per equivocaci, l'informem que
queda prohibida
la seva divulgaci, s o distribuci,
completa o en part, i li preguem esborri el missatge original juntament
amb els seus fitxers annexos
sense llegir-lo ni gravar-lo.
Grcies.
