[hibernate-dev] [HSEARCH] [Autodiscoverable] Handling duplicates

[Emmanuel Bernard]

On 01 Apr 2014, at 22:07, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at 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 `@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?