[hibernate-dev] [HSEARCH] Autodiscoverable field bridges next steps

[Hardy Ferentschik]

On 2 Jan 2014, at 23:20, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> Hardy, I am starting to come along your side on this discussion. They key things that made me swing is that if a user needs a special annotation to customize the bridge, then it’s equivalent to a @FieldBridge.

Exactly. And parameters you get in via @Parameter if you wan to 

> I am still a bit sceptical to move the bridge discovery to AMP - at least when explicit annotations are at play because:
> - AMP is complex

It is still very complex for sure. I would love to spend more time on this. Basically it is just an extraction of the annotation processing from the DocumentBuilder with the difference that is uses 
now the builder pattern. The basic flow is the same though. Complex or not, processing of the annotation belong there, either directly or in another helper called from there. If you feel for it
you can try to break up the whole class ;-)

> - BridgeFactory seems a nice focal point to everything bridge related

Right, all bridge related. That does imo not include dealing with annotations. We we said, o the BridgeFactory we could have things like buildSpatialBridge(…) which takes everything it needs 
to build such a bridge. However, the extraction of these parameter should happen as part of AnnotationMetadataProvider.

> - a few common rules must be applied to bridges (like the IterableBridges / MapBridges and ArrayBridges wrappers)

Maybe. I dig not deep enough to see all the required detail, but it should be solvable.

> Nevertheless the idea of inferring types via @FieldBridge, @TikeBridge, @DateBridge, @Spatial in a separate method than guessType has merits.

thanks

> BUT
> 
> In practice for Date related add-ons like JodaTime and Java 8 date, I am wondering if we should ensure that someone can use @DateBridge. After all a resolution is likely conceptually needed and forcing another annotation seems wrong.

This one is a border case. I could either handle this case specifically (not using the BridgeProvider) or we live with this shortcoming. It seems like a small flexibility loss and we would gain clearer design and API ;-)

> Likewise for "Hibernate Spatial” types, it will probably make sense to support them as annotated with @Spatial like we do for Coordinates.

I have a hard time that anyone wants to literally override the brig for @Spatial. Once you want to customise there, you might as well not use @Spatial and do your own stuff. Same for @TikaBridge. To a certain degree they are
just shorthands for @FieldBridge(impl=SpatialFoo.class).  

> - is that supposed to be supported by some other features unrelated to BridgeProvider?

Maybe. One idea could be to add a bridgeImpl attribute to @Spatial and @TikaBridge. But as said, see these two annotations more as already selecting one specific bridge type

> - should we design BridgeProvider in a way that let them react to these built in annotations? (via explicit methods I suppose).

Not for me. At least not for the first cut.

—Hardy