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

[Hardy Ferentschik]

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

>>> 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.

Got you

> ## 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:

Or we handle the ones with explicit annotation explicitly and let the BridgeFactory.guessType really just handle the ones we need to “guess”. Basically what we just discussed in the other thread regarding the BridgeProvider contract

> It offers more flexibility, like the ability to qualify a type with an annotation to discriminate which bridge is expected.

So if you already want to add an annotation to qualify the bridge, why do you not use @Bridge directly?

> 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”.

 "Allow loading of additional "built-in bridges" via auto discovery” - almost sounds like an oxymoron to me. There are built-in bridges and there are discovered bridges. The built-in ones are the ones for the basic data types 
as we define them in BridgeFactory plus the special bridges for spatial, tika, etc

When it comes to bridge auto discovery, I thick we should cover the case

- where a user wants to specify a bridge for a user specific type, so that he can just say @Field for this type
- where the user wants to override one of the basic bridges (String, Integer, …)

I say basic, since I am not sure whether we should consider overriding of @TikaBridge or @DateBridge. They are somewhat specific Search features. If you want to customise, you could just leave these annotations off altogether 
and provide a BridgeProvider for Lob and Date. Again, no loss in functionality. 

—Hardy