[hibernate-dev] [HSEARCH-566] Indexing null values for an @ElementCollection

[Emmanuel Bernard]

>> @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?
> 
> 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