[hibernate-dev] Hibernate Search 3.1

[Emmanuel Bernard]

On  May 2, 2008, at 03:33, Hardy Ferentschik wrote:

> Hi there,
>
> On Fri, 02 May 2008 01:53:02 +0200, Emmanuel Bernard <emmanuel at hibernate.org 
> > wrote:
>
>> Hibernate Search 3.1 will arrive sooner than expected to align with  
>> Hibernate Core 3.3
>
> Great. Seems a lot of things are finally happening, especially the  
> migration to maven on the core :) What is the long term plan with  
> the maven migration on Hibernate Search? How long will it be ivy/ant?

I am not doing it. If anyone has time...

>
>
>> If you have some compatibility breaks in mind, speak up. Also we  
>> need to focus on closing the features implying Core 3.3 first (I  
>> have the close hooks of the SF in mind but there might be others).  
>> The additional features will go in a 3.2. I don't know if we should  
>> go for a beta or straight to a CR for HSearch 3.1, WDYT.
>> There are code changes but there are not too big.
>
> I am still planing to implement indexing of null values  
> (HSEARCH-115), but that's goes probably falls under the category  
> 'not too big', even though I still thing we should change the  
> FieldBridge API. After last weeks discussions regarding this feature  
> I thought the bestway forward would be:
>
> 1. Go with Sanne's idea and introduce an additonal field in order to  
> index null values. Combined with Emmanuel's idea of a NullQuery it  
> should work quite well.

Just realizing it will not really work well inside collections. We  
need to think about that.

>
>
> 2. Instead of adding a new annotation like @IndexNullMarker I would  
> prefer to add another attribute to the @Field annotation.  
> Introducing a seperate annotation gives the impression that @Field  
> and @IndexNullMarker are orthogonal.
>

Right it does not work well with multiple fields per property either.

> 3. I also still believe that the actual work should be done in the  
> FieldBridge. For this reason the parameter would have to be passed  
> along into the bridge. Instead of just adding a parameter I am  
> toying with the idea of introducing some sort of wrapper object  
> containing values for index, store, boost, ...
>
>
> Should this be part of 3.1 or shall we move it to 3.2?

Time constraint, if you can get it in there, that's better.

>
>
> Cheers,
> Hardy
>