[hibernate-dev] Huge patch for Search

[Sanne Grinovero]

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/%3c50e5f6251002070933p4f9e6150t27ef86fd36ea59c2@mail.gmail.com%3e

Cheers,
Sanne

2010/2/8 Emmanuel Bernard <emmanuel at 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 <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
>
>