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

[Sanne Grinovero]

2011/8/1 Emmanuel Bernard <emmanuel at hibernate.org>:
>
>>> @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.

I don't want you to give up, nor I can find references on the forum to
find what exactly was said, so it was my impression that this syntax
was very clean and self speaking, but since we're discussing on it,
that's evidence enough that this is not self speaking at all so I'm
not backing my proposal anymore.

>>> ## 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

That's great, it is much cleaner. I was leaning for the "less
annotations, we can figure it out" but indeed I like the "least
surprise" principle more, and this is not more verbose either. Though
Davide will hate me as binding the bridge will need to be different
than his current pull request :)
Davide, what do you think of this? And can you add the agreed points
to the unit tests, mainly the DateBridge, resolution and NumericField
tests with custom precision, and above all checking for the capability
to override whatever your patch does with a custom bridge?

Sanne