Re: Best way for a query-expander?

2011-02-19 Thread Paul Libbrecht
Hello list,

as Hoss suggests, I'll try to be more detailed.

I wish to use http parameters in my requests that define the precise semantic 
of an advanced search.
For example, if I can see from sessions, that a given user is requesting, that 
not only public resources but resources private-to-him are returned.
For example, if there's a parameter ict, I want to expand the query with an 
extra (mandatory) term-query.

I know I could probably do this at the client level but I do not think this is 
the best way, in particular about the access to private resources... I also 
think it's better to not rely too heavily on client's ability to formula 
string-queries since it allows all sorts of tweaking that one may not wish 
possible, in particular for queries that are service oriented.

paul


Le 19 févr. 2011 à 01:18, Chris Hostetter a écrit :

 
 : I want to implement a query-expander, one that enriches the input by the 
 : usage of extra parameters that, for example, a form may provide.
 : 
 : Is the right way to subclass SearchHandler?
 : Or rather to subclass QueryComponent?
 
 This smells like the poster child for an X/Y problem 
 (or maybe an X/(Y OR Z) problem)...
 
 if you can elaborate a bit more on the type of enrichment you want to do, 
 it's highly likely that your goal can be met w/o needing to write a custom 
 plugin (i'm thinking particularly of the multitudes of parsers solr 
 already has, local params, and variable substitution)
 
 http://people.apache.org/~hossman/#xyproblem
 XY Problem
 
 Your question appears to be an XY Problem ... that is: you are dealing
 with X, you are assuming Y will help you, and you are asking about Y
 without giving more details about the X so that we can understand the
 full issue.  Perhaps the best solution doesn't involve Y at all?
 See Also: http://www.perlmonks.org/index.pl?node_id=542341
 
 
 -Hoss



RE: Best way for a query-expander?

2011-02-19 Thread Jonathan Rochkind
I don't think there's any way to do this in Solr, although you could write your 
own query parser in Java if you wanted to. 

You can set defaults , invariants  and appends values on your request 
handler, but I don't think that's flexible enough to do what you want. 
http://wiki.apache.org/solr/SearchHandler

In general, to my perspective, Solr seems to be written assuming a trusted 
client.  If you are allowing access to untrusted clients, there are probably 
all sorts of things a client can do that you woudln't want them to, writing 
your own query parser might be a good idea. 

From: Paul Libbrecht [p...@hoplahup.net]
Sent: Saturday, February 19, 2011 11:01 AM
To: solr-user@lucene.apache.org
Subject: Re: Best way for a query-expander?

Hello list,

as Hoss suggests, I'll try to be more detailed.

I wish to use http parameters in my requests that define the precise semantic 
of an advanced search.
For example, if I can see from sessions, that a given user is requesting, that 
not only public resources but resources private-to-him are returned.
For example, if there's a parameter ict, I want to expand the query with an 
extra (mandatory) term-query.

I know I could probably do this at the client level but I do not think this is 
the best way, in particular about the access to private resources... I also 
think it's better to not rely too heavily on client's ability to formula 
string-queries since it allows all sorts of tweaking that one may not wish 
possible, in particular for queries that are service oriented.

paul


Le 19 févr. 2011 à 01:18, Chris Hostetter a écrit :


 : I want to implement a query-expander, one that enriches the input by the
 : usage of extra parameters that, for example, a form may provide.
 :
 : Is the right way to subclass SearchHandler?
 : Or rather to subclass QueryComponent?

 This smells like the poster child for an X/Y problem
 (or maybe an X/(Y OR Z) problem)...

 if you can elaborate a bit more on the type of enrichment you want to do,
 it's highly likely that your goal can be met w/o needing to write a custom
 plugin (i'm thinking particularly of the multitudes of parsers solr
 already has, local params, and variable substitution)

 http://people.apache.org/~hossman/#xyproblem
 XY Problem

 Your question appears to be an XY Problem ... that is: you are dealing
 with X, you are assuming Y will help you, and you are asking about Y
 without giving more details about the X so that we can understand the
 full issue.  Perhaps the best solution doesn't involve Y at all?
 See Also: http://www.perlmonks.org/index.pl?node_id=542341


 -Hoss



Best way for a query-expander?

2011-02-18 Thread Paul Libbrecht

Hello Solr-friends,

I want to implement a query-expander, one that enriches the input by the usage 
of extra parameters that, for example, a form may provide.

Is the right way to subclass SearchHandler?
Or rather to subclass QueryComponent?

thanks in advance

paul

Re: Best way for a query-expander?

2011-02-18 Thread Em

Hi Paul,

what do you understand by saying extra parameters?

Regards


Paul Libbrecht-4 wrote:
 
 
 Hello Solr-friends,
 
 I want to implement a query-expander, one that enriches the input by the
 usage of extra parameters that, for example, a form may provide.
 
 Is the right way to subclass SearchHandler?
 Or rather to subclass QueryComponent?
 
 thanks in advance
 
 paul
 

-- 
View this message in context: 
http://lucene.472066.n3.nabble.com/Best-way-for-a-query-expander-tp2528194p2528736.html
Sent from the Solr - User mailing list archive at Nabble.com.


Re: Best way for a query-expander?

2011-02-18 Thread Paul Libbrecht
Erm... extra web-request-parameters simply.

paul


Le 18 févr. 2011 à 19:37, Em a écrit :

 
 Hi Paul,
 
 what do you understand by saying extra parameters?
 
 Regards
 
 
 Paul Libbrecht-4 wrote:
 
 
 Hello Solr-friends,
 
 I want to implement a query-expander, one that enriches the input by the
 usage of extra parameters that, for example, a form may provide.
 
 Is the right way to subclass SearchHandler?
 Or rather to subclass QueryComponent?
 
 thanks in advance



Re: Best way for a query-expander?

2011-02-18 Thread Tommaso Teofili
Hi Paul,
me and a colleague worked on a QParserPlugin to expand alias field names
to many existing field names
ex: q=mockfield:val == q=actualfield1:val OR actualfield2:val
but if you want to be able to use other params that come from the HTTP
request you should use a custom RequestHandler I think,
My 2 cents,
Tommaso


2011/2/18 Em mailformailingli...@yahoo.de


 Hi Paul,

 what do you understand by saying extra parameters?

 Regards


 Paul Libbrecht-4 wrote:
 
 
  Hello Solr-friends,
 
  I want to implement a query-expander, one that enriches the input by the
  usage of extra parameters that, for example, a form may provide.
 
  Is the right way to subclass SearchHandler?
  Or rather to subclass QueryComponent?
 
  thanks in advance
 
  paul
 

 --
 View this message in context:
 http://lucene.472066.n3.nabble.com/Best-way-for-a-query-expander-tp2528194p2528736.html
 Sent from the Solr - User mailing list archive at Nabble.com.



Re: Best way for a query-expander?

2011-02-18 Thread Paul Libbrecht

using rb.req.getParams().get(blip) inside prepare(ResponseBuilder)'s subclass 
of QueryComponent I could easily get the extra http request param.

However, how would I change the query?
using rb.setQuery(xxx) within that same prepare method seems to have no effect.


paul

Le 18 févr. 2011 à 19:51, Tommaso Teofili a écrit :

 Hi Paul,
 me and a colleague worked on a QParserPlugin to expand alias field names
 to many existing field names
 ex: q=mockfield:val == q=actualfield1:val OR actualfield2:val
 but if you want to be able to use other params that come from the HTTP
 request you should use a custom RequestHandler I think,
 My 2 cents,
 Tommaso
 
 
 2011/2/18 Em mailformailingli...@yahoo.de
 
 
 Hi Paul,
 
 what do you understand by saying extra parameters?
 
 Regards
 
 
 Paul Libbrecht-4 wrote:
 
 
 Hello Solr-friends,
 
 I want to implement a query-expander, one that enriches the input by the
 usage of extra parameters that, for example, a form may provide.
 
 Is the right way to subclass SearchHandler?
 Or rather to subclass QueryComponent?
 
 thanks in advance
 
 paul
 
 
 --
 View this message in context:
 http://lucene.472066.n3.nabble.com/Best-way-for-a-query-expander-tp2528194p2528736.html
 Sent from the Solr - User mailing list archive at Nabble.com.
 



Re: Best way for a query-expander?

2011-02-18 Thread Paul Libbrecht
it does work!

Le 18 févr. 2011 à 20:48, Paul Libbrecht a écrit :

 using rb.req.getParams().get(blip) inside prepare(ResponseBuilder)'s 
 subclass of QueryComponent I could easily get the extra http request param.
 
 However, how would I change the query?
 using rb.setQuery(xxx) within that same prepare method seems to have no 
 effect.

Sorry for the noise, it does have the exact desired effect.

Nice pattern.
I believe everyone needs query expansion except maybe if using Dismax.

paul

 
 Le 18 févr. 2011 à 19:51, Tommaso Teofili a écrit :
 
 Hi Paul,
 me and a colleague worked on a QParserPlugin to expand alias field names
 to many existing field names
 ex: q=mockfield:val == q=actualfield1:val OR actualfield2:val
 but if you want to be able to use other params that come from the HTTP
 request you should use a custom RequestHandler I think,
 My 2 cents,
 Tommaso
 



Re: Best way for a query-expander?

2011-02-18 Thread Chris Hostetter

: I want to implement a query-expander, one that enriches the input by the 
: usage of extra parameters that, for example, a form may provide.
: 
: Is the right way to subclass SearchHandler?
: Or rather to subclass QueryComponent?

This smells like the poster child for an X/Y problem 
(or maybe an X/(Y OR Z) problem)...

if you can elaborate a bit more on the type of enrichment you want to do, 
it's highly likely that your goal can be met w/o needing to write a custom 
plugin (i'm thinking particularly of the multitudes of parsers solr 
already has, local params, and variable substitution)

http://people.apache.org/~hossman/#xyproblem
XY Problem

Your question appears to be an XY Problem ... that is: you are dealing
with X, you are assuming Y will help you, and you are asking about Y
without giving more details about the X so that we can understand the
full issue.  Perhaps the best solution doesn't involve Y at all?
See Also: http://www.perlmonks.org/index.pl?node_id=542341


-Hoss