[hibernate-dev] API changes in FieldBridge

[Sanne Grinovero]

On 7 September 2011 13:17, Sanne Grinovero <sanne at hibernate.org> wrote:
> On 7 September 2011 13:04, Emmanuel Bernard <emmanuel at hibernate.org> 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 the FieldBridge interface *even more* by disallowing it
>>> to write directly to Document, but have it return a single String,
>>> effectively forcing implementors to write to a single field which we
>>> know about, and for which we can extrapolate all kind of
>>> optimisations. This has the nice side-effect as the implementation
>>> would be greatly simplified and not have to deal with LuceneOptions
>>> and Document interfaces.
>>>
>>> We could have it return a Fieldable or a String; for the Fieldable I'd
>>> check the field name is the expected one.
>>
>> 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 exists.
>
> Right that would fit perfectly, but the mapping annotations take a
> FieldBridge implementation (@Field, @FieldBridge) so while the most
> common case is likely applying a StringBridge via it's
> TwoWayString2FieldBridgeAdaptor, we're still dealing with a
> FieldBridge.
> This seems to suggest we should treat the optimisations differently by
> checking if the implementation is a TwoWayString2FieldBridgeAdaptor,
> and add what we eventually need to this internal class.

sorry let me amend this. That won't be enough, as our goal is to make
it possible for people to plug in custom implementations of
TwoWayStringBridge.
Should be good enough to allow passing to these annotations either a
class implementing TwoWayFieldBridge or implementing
TwoWayStringBridge ?
The in case of a TwoWayFieldBridge we can additionally check if it
happens to be a TwoWayString2FieldBridgeAdaptor.

This all looks like to boil down to the fact that we don't need to
change backwards compatible APIs, WDYT, should these optimisations be
coded in a version > 4.0 ?