On 2 Jan 2014, at 23:20, Emmanuel Bernard <emmanuel(a)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