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

[Sanne Grinovero]

2011/8/1 Emmanuel Bernard <emmanuel at hibernate.org>:
>
> On 1 août 2011, at 10:31, Sanne Grinovero wrote:
>
>> 2011/8/1 Emmanuel Bernard <emmanuel at 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.

Of course, but I had to give hints about implementing one quite often
for these simple cases which could be figured out by Search without
the need for more custom bridges nor annotations.

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

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

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