[hibernate-dev] Huge patch for Search

[Emmanuel Bernard]

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/%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
>> 
>>