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
>> 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.
No, the mapping annotation accepts StringBridge / FieldBridge and their TwoWay
counterparts.
> 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.
That made me realize. Most of our bridges are stateless wrt the field name. ie
the field name is passed as a parameter and we use it. Even many user provided
FieldBridge will be like that. Which means getTargetedFieldNames() is not
implementable for such bridges.
One alternative approach would be to use annotations on the FieldBridge
implementation
@TargetedFields(value=PROVIDED_FIELD_NAME)
@TargetedFields(value=FIELD_LIST, fieldList={"foo", "bar"})
@TargetedFields(value=ALL)
we can even later implement if that makes sense
@TargetedFields(value=FIELD_PREFIXES, fieldList="foo") //all fields starting
with foo
Most of our fields would use @TargetedFields(value=PROVIDED_FIELD_NAME)
The names are not good yet but you get the idea.
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
