I'd love to see a formal syntax like this officially enter the Lucene
standard query language someday.
I doubt that this is something that is ever going to really happen.
There are a couple of approaches to the problem and there are other
similar problems (like allowing stemmed and unstemmed searches) and I
think you are going to be stuck with roll your own for this type of
thing. The problem with it being in the syntax is that it requires you
to use certain analyzer's and indexing schemes...something not
guaranteed...and if you where to add a case sensitive approach to the
core of Lucene it would slow down the common case for a somewhat rare
case. I think the brilliance of Lucenes approach is that it provides
building blocks for your own search solution. I wouldn't consider it out
of the normal to write your own parser or modify Lucenes parser...I
think a lot of people do. Your solution is a good one, and I think its
the right approach with Lucene...there are a lot of cool things you can
do with different analyzers and token positions...but adding more
support than what is there will tie down the sweet open endedness. Maybe
a sandbox package with all of the necessary analyzers and the modified
query parser would be more likely...even still it seems a lot of stuff
does not even make the sandbox. These guys keep quite intent on keeping
Lucene lean and mean and I am quite thankful for it.
As far as solr, a lot of the code can just be stolen or you might check
out embedded solr and I think there is something else similar to
embedded solr that might not require a web server...
- Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
