lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Updated: (LUCENE-682) QueryParser with Locale Based Operators (French included)
Date Mon, 20 Nov 2006 08:37:03 GMT
     [ ]

Hoss Man updated LUCENE-682:

    Attachment: LocalizedQueryParser.patch

LocalizedQueryParser.patch contains everything in the most recent,
except in patch form, with a few minor changes...
  1) moved files into tree as appropraite
  2) reformated (\t to 2 spaces, license header in test)
  3) included javacc generated QueryParser*.java since they 
       need to be commited too.
  4) added <copy> directive to build.xml so property files 
      would make it into jar (and classpath for tests)

The code looks *great* and the unit tests provide nice coverage.

Like Otis, I'm also a little worried about the createLocalizedTokenMap() calls ... the ResourceBundle
lookups *may* be cached, but there's also the splitting, and the fact that createLocalizedTokenMap()
is called in both setLocale and setUseLocalizedOperators ... setLocale might be used just
for the date parsing, so that could result in wasted cycles for some people ... not to mention
setBundleBaseName *doesn't* call createLocalizedTokenMap so people who do...

   QueryParser qp = new QueryParser

...will wind up triggering createLocalizedTokenMap twice, and still not use the Bundle the
wanted to.

Even if we don't want to worry about caching the post-split arrays per Bundle, I think it
might make more sense if setUseLocalizedOperators was the only method that called createLocalizedTokenMap,
and it was documented that if should be called *after* setLocale and setBundleBaseName.

   ...any other opinions on this?

Other things that should probably be done before commiting:

  a) have at least one test using a Bundle that excercises 
      the splitting.
  b) add some javadoc verbage to QueryParser.setLocale 
      clarifying how it affects the operators.

...I may be able to find some time to play with this some more later this week and make those
changes myself.

> QueryParser with Locale Based Operators (French included)
> ---------------------------------------------------------
>                 Key: LUCENE-682
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: QueryParser
>            Reporter: Patrick Turcotte
>            Priority: Minor
>         Attachments: LocalizedQueryParser.patch,,,
QueryParser.jj, QueryParser.jj.patch,,,
> Here is a version of the QueryParser that can "understand" the AND, OR and NOT keyword
in other languages.
> If activated, 
> - "a ET b" should return the same query as "a AND b", namely: "+a +b"
> - "a OU b" should return the same query as "a OR b", namely: "a b"
> - "a SAUF b" should return the same query as "a NOT b", namely: "a -b"
> Here are its main points : 
> 1) Patched from revision 454774 of lucene 2.1dev (trunk) (probably could be used with
other versions)
> 2) The "ant test" target is still successful when the modified QueryParser is used
> 3) It doesn't break actual code
> 4) The default behavior is the same as before
> 5) It has to be deliberately activated
> 6) It use ResourceBundle to find the keywords translation
> 7) Comes with FRENCH translation
> 8) Comes with JUnit testCases
> 9) Adds 1 public method to QueryParser
> 10) Expands the TOKEN <TERM>
> 11) Use TOKEN_MGR_DECLS to set some field for the TokenManager

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message