On 1 août 2011, at 10:31, Sanne Grinovero wrote:
> 2011/8/1 Emmanuel Bernard <emman...@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=@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.
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
