Re: [hibernate-dev] [HSEARCH] [Autodiscoverable] Handling duplicates
On 2 Jan 2014, at 14:30, Emmanuel Bernard <emmanuel(a)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