lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Elschot <paul.elsc...@xs4all.nl>
Subject Re: contrib/queryParsers/surround
Date Sun, 29 May 2005 19:15:23 GMT
On Sunday 29 May 2005 20:03, Wolfgang Hoschek wrote:
> Folding the surround syntax into the standard query parser would be  
> great indeed!
> I'd very much encourage the increased power and expressiveness lucene  
> would gain through that.
> 
> Wolfgang.
> 
> On May 29, 2005, at 9:33 AM, Otis Gospodnetic wrote:
> 
> 
> > --- Erik Hatcher <erik@ehatchersolutions.com> wrote:
> >
> >
> >>
> >> On May 28, 2005, at 10:04 AM, Paul Elschot wrote:
> >>
> >>
> >>> Dear readers,
> >>>
> >>> I've started moving the surround query language
> >>> http://issues.apache.org/bugzilla/show_bug.cgi?id=34331
> >>> into the directory named by the title in my working copy of the
> >>>
> >>>
> >> lucene
> >>
> >>
> >>> trunk. When the tests pass I'll repost it there.
> >>> In case someone  needs this earlier, please holler.
> >>>
> >>>
> >>
> >> As for naming conventions and where this should live in contrib,
> >> consider that a user will only want a single query parser and more
> >> than that would be unneeded bloat in her application.  The contrib
> >> pieces are all packaged as a separate JAR per directory under
> >> contrib.

The parser package as contributed is in the class:
org.apache.lucene.queryParser.surround.parser.QueryParser
and there is also a ...surround.query package.
Please feel free to improve this, if needed.

> >>
> >>
> >
> > I agree, a typical user would want just one query parser to handle all
> > types of queries.  So wouldn't it be better to fold Paul's Surround
> > query parser into Lucene's current query parser?
> >
> > Otherwise, the user will have to use tricks to detect that the entered
> > query uses Surround query syntax and use Surround query parser  
> > instead,
> > no?

Currently, yes. Some queries are legal in both syntaxes, so that would
not be any easy thing to detect beforehand. Since the surround syntax
is quite strict, one way might be to catch a parse exception from the
surround parser, and in that case use the default parser.
It's a hack, but it might work well in practice for users that explicitly want
to use them both at the same time.
Removing the lowercase operators from  the surround syntax would
probably reduce the confusion to a tolerable level in this case.

At the moment, the syntax is not cast in stone because afaik only
the test code depends on it.

> > Otis
> >
> >
> >
> >
> >> My recommendation would be to put your wonderful surround parser and
> >>
> >> supporting infrastructure under contrib/surround.

The only dependency to the lucene environment is currently in
the ../../ path name used to locate the lucene core jar.

Regards,
Paul Elschot


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message