Hi there,
On Fri, 02 May 2008 01:53:02 +0200, Emmanuel Bernard
<emmanuel(a)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?
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.
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.
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?
Cheers,
Hardy