You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Will Sexton <wi...@duke.edu> on 2007/01/25 04:58:50 UTC

form handling and query syntax

I'm looking to use SOLR to replace the search components of a 
Lucene-based application I built a few years ago.  One bit of 
functionality that I'm not seeing is how to handle form input and 
translate it to Lucene QueryParser syntax to pass into the SOLR servlet. 
  An example of the kind of search form that I need to support can be 
seen here:

http://scriptorium.lib.duke.edu/road/search-advanced.htm

The form submits to my existing application, and searches a database of 
 >50k records related to advertising materials.  The researchers who use 
the database like to do queries along the lines of:

company=Johnson AND product=sunscreen

It's not hard to formulate a Lucene query string to accommodate this 
query.  I'm just not sure of the preferred mechanism by which I can do 
it with SOLR, where the servlet asks for a 'q' parameter specifying a 
fully-formed query string.  I can think of several ways:

1) Use JavaScript on the search form to piece together the Lucene query 
string with the onSubmit action.  It'll work, but, well ... JavaScript.

2) Submit to a different servlet of my own design, which interprets the 
form input, forms the Lucene query string, adds it to a SOLR request 
URL, gets the output of the REST response and does something with it, 
probably doing an XSLT transformation.  This method resembles how my old 
app works, and while it's certainly possible, it requires maintaining a 
separate servlet, and it represents the kind of complexity I'm trying to 
get away from.

3) Write a custom class which extends SolrRequestHandler.  Basically, 
this handler is going to compare the request parameters to the fields 
specified in the schema.xml document, and where the name of a form input 
and a field name match, form the query from those request parameters. It 
seems like the most elegant solution, and while I'll have to write 
custom code, most of the complexity will be farmed out to SOLR.

I'm prepared to take the approach of #3, but I just want to establish 
that a) it's a faithful use of SolrRequestHandler and b) I'm not missing 
something ridiculously obvious in how to use SOLR.

Appreciate any advice,

Will
-- 
Will Sexton
Metadata Analyst / Programmer
Duke University Libraries



Re: form handling and query syntax

Posted by Chris Hostetter <ho...@fucit.org>.
: 2) Submit to a different servlet of my own design, which interprets the
: form input, forms the Lucene query string, adds it to a SOLR request
: URL, gets the output of the REST response and does something with it,
: probably doing an XSLT transformation.  This method resembles how my old
: app works, and while it's certainly possible, it requires maintaining a
: separate servlet, and it represents the kind of complexity I'm trying to
: get away from.

#2 is the mehtod i would normally recommend for most people.  Solr makes
no attempt at being a "secure" sservice -- if you let users in the wild
talk to your Solr server directly you run the risk that they may attempt
to do things you don't want them to do.  Solr has no idea what kinds of
things you want to allow, only you do: putting an application in front of
your Solr instance that knows what you want to allow/disallow is how you
enforce your wishes.

See also this comment i made regarding a similar question...

http://www.nabble.com/Re%3A-filter-input-from-multiple-fields-p8038721.html

: 3) Write a custom class which extends SolrRequestHandler.  Basically,
: this handler is going to compare the request parameters to the fields
: specified in the schema.xml document, and where the name of a form input
: and a field name match, form the query from those request parameters. It
: seems like the most elegant solution, and while I'll have to write
: custom code, most of the complexity will be farmed out to SOLR.

this is a perfectly valid approach, and something i've done quite a bit at
work -- but there i'm providing a web-service-ish API to *trusted* clients
... not to end users.


-Hoss