We often had trouble applying strong optimisations because of the
flexibility of the FieldBridge API, since 4.0 is coming it's time to
decide if these limitations are going to stay, or if we have to change
the contract.
As far as I remember we can classify these limitations in two main areas:
1# w
Hi,
there is also HSEARCH-664 which is related to this discussion.
One alternative to modifying the bridge API is to add a new interface, eg
FieldBridgeMetaDataProvider. Custom bridges (and also our built-in ones)
could
implement the method(s) in this interface to provide additional metadata
l
#1
A specific interface is what looks the best to me too.
#2 we might be able to reuse #1's interface.
I don't fully understand what allowSkipOnUnchangedFields does.
On 7 sept. 2011, at 12:08, Sanne Grinovero wrote:
> We often had trouble applying strong optimisations because of the
> flexibil
Hi Hardy,
if we decide that we don't have to break existing implementations, I'd
translate that into "move it out of 4.0".
What about this mid-in solution:
# we simplify the FieldBridge interface *even more* by disallowing it
to write directly to Document, but have it return a single String,
effe
On 7 September 2011 12:43, Emmanuel Bernard wrote:
> #1
> A specific interface is what looks the best to me too.
>
> #2 we might be able to reuse #1's interface.
> I don't fully understand what allowSkipOnUnchangedFields does.
I think we need a way for implementors to state that the index needs
t
On 7 sept. 2011, at 12:56, Sanne Grinovero wrote:
> Hi Hardy,
> if we decide that we don't have to break existing implementations, I'd
> translate that into "move it out of 4.0".
>
> What about this mid-in solution:
>
> # we simplify the FieldBridge interface *even more* by disallowing it
> to
On 7 sept. 2011, at 13:01, Sanne Grinovero wrote:
> On 7 September 2011 12:43, Emmanuel Bernard wrote:
>> #1
>> A specific interface is what looks the best to me too.
>>
>> #2 we might be able to reuse #1's interface.
>> I don't fully understand what allowSkipOnUnchangedFields does.
>
> I thin
On 7 September 2011 13:04, Emmanuel Bernard wrote:
>
> On 7 sept. 2011, at 12:56, Sanne Grinovero wrote:
>
>> Hi Hardy,
>> if we decide that we don't have to break existing implementations, I'd
>> translate that into "move it out of 4.0".
>>
>> What about this mid-in solution:
>>
>> # we simplify
On 7 September 2011 13:17, Sanne Grinovero wrote:
> On 7 September 2011 13:04, Emmanuel Bernard wrote:
>>
>> On 7 sept. 2011, at 12:56, Sanne Grinovero wrote:
>>
>>> Hi Hardy,
>>> if we decide that we don't have to break existing implementations, I'd
>>> translate that into "move it out of 4.0".
>
> OK, got it.
> The absence of this TargetedFields (or whatever name we could give it)
> interface would be equivalent to allowSkipOnUnchangedField = false for a
> bridge. Likewise for DynamicBoost and DynamicAnalyzer.
> Of course an additional interface is less in your face than an explicit
>
On Wed, 07 Sep 2011 12:56:26 +0200, Sanne Grinovero
wrote:
> if we decide that we don't have to break existing implementations, I'd
> translate that into "move it out of 4.0".
It does not HAVE TO be moved out in this case. It will really depend if
one of
us has time to work on this. On the o
On 7 sept. 2011, at 13:17, Sanne Grinovero wrote:
>>
>> We already have a simple interface for common use cases, it's StringBridge /
>> TwoWayStringBridge. FieldBridge is for complex use cases by essence. I might
>> miss something but it looks like you are inventing something that already
>>
On Wed, 07 Sep 2011 13:27:17 +0200, Sanne Grinovero
wrote:
>>
>> OK, got it.
>> The absence of this TargetedFields (or whatever name we could give it)
>> interface would be equivalent to allowSkipOnUnchangedField = false for
>> a bridge. Likewise for DynamicBoost and DynamicAnalyzer.
>> Of
Summary: we won't use the annotations, but we will add additional
Interfaces in future, which will be optional.
The only change needed for 4.0 to make this possible later is to make
the FieldBridge implementations stateful: they will need an initialize
method
to receive the field name and LuceneOpt
I had to read the conversation quickly. A couple of comments.
I am concerned about making FieldBridge a stateful component, this will
increase our metadata footprint by a lot. Most bridges are currently
singletons. This won't be possible with this new design approach.
LucemeOptions is not so mu
On 7 September 2011 20:07, Emmanuel Bernard wrote:
> I had to read the conversation quickly. A couple of comments.
>
> I am concerned about making FieldBridge a stateful component, this will
> increase our metadata footprint by a lot. Most bridges are currently
> singletons. This won't be possib
On Wed, 07 Sep 2011 20:07:42 +0200, Emmanuel Bernard
wrote:
> I am concerned about making FieldBridge a stateful component, this will
> increase our metadata footprint by a lot. Most bridges are currently
> singletons. This won't be possible with this new design approach.
do you really thi
this has caused many times our hudson job fail due to using JDK 6 api or using
@Override annotation on a method that does not actually override a superclass
method (but an interface).
---
Strong Liu
http://hibernate.org
http://github.com/stliu
___
18 matches
Mail list logo
