Re: [hibernate-dev] [HSEARCH] [Autodiscoverable] Handling duplicates
On 01 Apr 2014, at 22:07, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> ## Handling duplicates
>
> I had in mind the following logic.
>
> Prevent custom bridge providers to offer bridges in the same situation.
What do you mean with "in the same situation”? You mean there cannot be two bridge
providers for the same return type (assuming no dedicated bridge annotation)
I mean for the same set of parameters passed to BridgeFactory.guessType(…).
> That would be an error at start up time as the alternative of picking up one of them
does not seem very attractive.
How do you determine bridge providers providing bridges for the “same situation”?
More than one BridgeProvider.returnFieldBridgeIfMatching (or canProvideFieldBridge())
returns a field bridge instance.
> Sanne questioned the idea of built-in bridge and would rather have all bridges
handled equally and not allow duplication.
> It seems that the current set of bridges cannot support that approach. When I
developed the code, I realised that there is an ordering to respect. If I put the
TikeBridgeProvider logic before the date and calendar bridgeProviders, then the DSLTest
fails. I could not find why but it shows that we have some interdependencies at the
moment.
I think it would be a good idea to fine out what’s going on first.
So the TikaBridge problem was due to a test placing @TikaBridge on a Date (`@TikaBridge
Date someDate`)
- If @TikaBridge is placed on an unknown type, the bridge fails and the test checks that.
- if the DateBridgeProvider runs before the TikeBridgeProvider then the exception does not
happen as the DataBridgeProvider not only checks for `@DateBridge` but also for naked
`Date` return type and wins over tike bridge.
## Option A
We could force all discoverable bridges to only handle bridges with an explicit annotation
e.g. `@MyBridge SomeType`. And handle the non annotated types in the last phase of the
BridgeFactory.guessType but a few questions arise:
- can an BridgeProvider accepting annotated types override the bridges that would be
provided by the non annotated type logic at the bottom of guessType?
- if yes, how is that significantly different than my initial ordering proposal
- is it acceptable to impose to annotate all members receiving a BridgeProvider’s bridge?
That seems to go against the idea of autodiscoverable bridges as `@MyBridge` is not
significantly different than `(a)FieldBridge(implMyFB.class)`
## Option B
An alternative is to impose that only a single BridgeProvider could answer for a given
return type.
## Option C
My gut feeling is that it’s a bit too restrictive and I’d prefer to allow:
- user provided BridgeProvider to override the core BridgeProviders
- raise an exception if two user provided bridge providers answer for the same
guessType(…) call.
It offers more flexibility, like the ability to qualify a type with an annotation to
discriminate which bridge is expected. But that raises the question of the naked types
(i.e. no annotated). To answer that problem we either:
- not allow the mix of naked types and annotated types (by two different providers)
- allow it but have two methods on BridgeProvider. One for annotated types (qualified) and
one for naked types. We could run the latter phase after the former phase and only
complain if two bridge providers react for a single phase.
I’m fine with starting with option B but latter moving to option C will break backward
compatibility. So in the end the question is what do you mean precisely by "Allow
loading of additional "built-in bridges" via autodiscovery”.
Thoughts?