1:53 a.m.
Hibernate Search 3.1 will arrive sooner than expected to align with
Hibernate Core 3.3
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.
Emmanuel
PS I had hoped to keep HSearch 3.1 compatible with Core 3.2 but
because we extends Session (which has a new doWork(Work) method), we a
pretty much screwed.
9:33 a.m.
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
3:29 p.m.
On May 2, 2008, at 03:33, Hardy Ferentschik wrote:
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?
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
5845
days inactive
5846
days old
2 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Hardy Ferentschik