[hibernate-dev] API changes in FieldBridge

[Sanne Grinovero]

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.

>> # we create the new interface as you say which is going to be the more
>> powerful one, but an alternative rather than an extension, supporting
>> the full Document customization: adding multiple fields, overriding
>> indexing options.
>> Then we mandate on implementors of this one only to list the field
>> names being potentially used for a Document->Object conversion.
>
> Note that this is not always possible. Sometimes the field name depends on the data being indexed (think map key being part of the name).

Right, it should be possible to say "I can't know, please return them
all" and have any field-loading optimisation strategy disabled.