> @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?
TBH I didn't think about Date, that's clearly a special case as it
selects a FieldBridge without actually using the @FieldBridge
annotation.
> You would let people set a @Resolution and be applied to the elements?
+1, as in:
@Field
@DateBridge(resolution=Resolution.DAY)
private Set<Date> views;
I think it's quite clear what the user meant to do, don't you?
I personally find it confusing that we reuse the same @Field at the same place for a
different target. But if people are of the opposite opinion, I can give up.
> ## How about NumericField?
>
> Same as @Resolution?
yes, but simpler to implement as it's taken care of the LuceneOptions
already (AFAIK, a test might proof me wrong).
The example would read
@Field
@NumericField(precisionStep=8)
private Set<Integer> views;
>
> ## 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.
I think we don't have limitations, as people will still be able to use
@FieldBridge to override anything, as was mandatory before adding this
feature.
## @ElementCollection on embeddable objects
should this work the same as @IndexedEmbedded, or should it throw an
error inviting to use that one instead?
ahh, here is an idea
I would rewrite the examples above as
@IndexedEmbedded
@DateBridge(resolution=Resolution.DAY)
private Set<Date> views;
@IndexedEmbedded
@NumericField(precisionStep=8)
private Set<Integer> views;
Of course this clashes in case people want both the proposed behavior and use a custom
field bridge in parallel. But such feature is not supported by the currently proposed
syntax either