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 first place) - this model does not work for third party analyzers unless you multiply the number of version dependencies and then it becomes utterly confusing. - it increases the complexity matrix. A user has to provide the Lucene version + the passed version for each analyzer (and affiliated) used Java 7 and Jigsaw could solve some of those problems (though not all). At the end of the day, I wonder if this will not create more issues than the ones it is preventing. I hope I'm wrong. On 8 févr. 2010, at 12:13, Sanne Grinovero wrote: > 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 Bernard <emman...@hibernate.org>: >> 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 complexity to the user. So I >> don't think migrating the test suite further makes sense. >> >> +1 for the commit with the addition of getTargetLuceneVersion() >> >> On 7 févr. 2010, at 22:53, Sanne Grinovero wrote: >> >>> 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 construction, and in many >>> other features. I didn't use a single constant because I was trying to >>> follow Emmanuel's direction of having the tests look as good examples. >>> On the Lucene community (see mailing list) they're strongly advising >>> me against using the LUCENE_CURRENT value, but to use a parameter for >>> the testsuite; >>> so I'll have to add some helper method in SearchTestCase (or other >>> utility) like "getTargetLuceneVersion()". >>> For now I'll only introduce the getter method returning >>> LUCENE_CURRENT, so we can later introduce logic in this getter and >>> eventually run tests on different versions (like a parameter of the >>> maven profile). >>> >>> What about moving the QueryParser building to this utility class? >>> Seems a logic move to encapsulate a bit more, but it will loose even >>> more expression as a readable example. >>> >>> Sanne >>> >>> >>> 2010/2/7 Hardy Ferentschik <hibern...@ferentschik.de>: >>>> Fine with me :) >>>> >>>> On Sun, 07 Feb 2010 15:50:13 -0300, Sanne Grinovero >>>> <sanne.grinov...@gmail.com> 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 the way we use Lucene's API, for each deprecated method >>>>> I've rewritten it to use the new API, >>>>> so the immediate effect will be to only reduce some warnings, but this >>>>> is going to be a requirement when switching to Lucene 3.x >>>>> (Lucene 2.9 deprecated the APIs, 3.x removed them) >>>>> >>>>> ok for commit? >>>>> If you need to take a look inside, I've attached the patch to JIRA. >>>>> >>>>> This is not about upgrading to Lucene3: it's still compatible with >>>>> 2.9, but will make upgrade easier later. >>>> >>>> >>>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
