Re: [hibernate-dev] [HSEARCH-566] Indexing null values for an @ElementCollection
On 1 août 2011, at 10:31, Sanne Grinovero wrote:
2011/8/1 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> On 31 juil. 2011, at 21:44, Sanne Grinovero wrote:
>
>> @ElementCollection
>> @Field(indexNullAsl="nullToken")
>> String[] tags
>
> Hum is it really the way we are going? ie @Field would be used by the elements of the
collection if it's a collection?
>
> I'm not a big fan for a couple of reasons:
>
> - it breaks backward compatibility
> - I cannot write a custom collection bridge
How is this breaking backwards compatibility, when this was previously
not supported? This was needing a field bridge, and since I've been
suggesting many times on the forum how to add multiple fields, it
seems a common use case.
You have always been able to write a FieldBridge that accepts a Collection and do whatever
you want in it.
@Field(bridge=(a)FieldBridge(impl=CustomCollFB.class)
public Collection<String> getNames() { ... }
I think this new bridge could be applied to the elements in this
case,
but be overridden by a custom bridge: so if someone was defining his
own custom bridge it would still be applied instead.
The point of the feature is that when mapping collections of
primitives, people don't need to provide a custom bridge, and @Field
is all what is needed to index the elements; of course this should not
prevent more advanced mappings.
So you're saying that assuming you're OK with the default bridges, the elements of
the collection will be indexed, but the minute you override the @FieldBridge, we default
back to the existing behavior ie be a bridge accepting the collection.
Is that correct?
## How about Date resolution?
You would let people set a @Resolution and be applied to the elements?
## How about NumericField?
Same as @Resolution?
## Custom bridge for elements
If a user wants a custom bridge for the elements, he needs to write a custom bridge
accepting the collection. Is that correct?
I'm trying to get a grasp on the limitations.