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