[hibernate-dev] Huge patch for Search

Emmanuel Bernard emmanuel at hibernate.org
Mon Feb 8 06:02:49 EST 2010


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 <hibernate at ferentschik.de>:
>> Fine with me :)
>> 
>> On Sun, 07 Feb 2010 15:50:13 -0300, Sanne Grinovero
>> <sanne.grinovero at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev





More information about the hibernate-dev mailing list