So someone changing the behavior of an analyzer should fallback to the previous
behavior if an old version number is passed.
What I fear with this approach is that:
- you cannot see at compile time which analyzer has changed and which one has
not (which is what people are interested in in the f
ok will fix and apply
About the Version, I've started a thread on Lucene-dev and got many
interesting answers and insight:
http://mail-archives.apache.org/mod_mbox/lucene-java-dev/201002.mbox/%3c50e5f6251002070933p4f9e6150t27ef86fd36ea5...@mail.gmail.com%3e
Cheers,
Sanne
2010/2/8 Emmanuel Bernar
Right, the spreading of this constant is a bit worrisome but it seems to be the
way Lucene is going.
I think getTargetLuceneVersion() is a good addition to SearchTestCase.
In the hopefully near future, this constant will be a parameter of Hibernate
Search at runtime. The DSL will absorb this com
Actually the patch is needing an update;
I'm extensively using a syntax like :
QueryParser parser = new QueryParser( Version.LUCENE_CURRENT, "id",
SearchTestCase.standardAnalyzer );
This "Version" constant is spread around everywhere, you have to
specify it at every QueryParser and Analyzer constr
Fine with me :)
On Sun, 07 Feb 2010 15:50:13 -0300, Sanne Grinovero
wrote:
> Hello,
> I've prepared a patch for HSEARCH-458, there's nothing critically
> complex inside but it's more than 3000 lines of tedious work.
> It patches almost nothing in main, nearly all classes in test.
> It changes
Hello,
I've prepared a patch for HSEARCH-458, there's nothing critically
complex inside but it's more than 3000 lines of tedious work.
It patches almost nothing in main, nearly all classes in test.
It changes the way we use Lucene's API, for each deprecated method
I've rewritten it to use the new A
