On Mon, 01 Aug 2011 14:04:58 +0200, Emmanuel Bernard
wrote:
> Note that @ElementCollection is the JPA annotation that might or might
> not be present (HSearch on Infinispan doesn't use JPA annotations).
Right. I was just talking about the overall number of annotations (be it
JPA or Search)
[resending as the previous one was from the wrong account]
> I find @IndexedEmbedded as ambiguous, besides you are adding an additional
> annotation
> since @ElementCollection is still there, right? Just saying there are
> quite a few annotations.
I agree we should minimize the number of annotati
>>> @IndexedEmbedded
>>> @DateBridge(resolution=Resolution.DAY)
>>> private Set 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
>>
>
On Mon, 01 Aug 2011 13:01:02 +0200, Sanne Grinovero
wrote:
>>> @Field
>>> @DateBridge(resolution=Resolution.DAY)
>>> private Set 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 pla
2011/8/1 Emmanuel Bernard :
>
>>> @Field(bridge=@FieldBridge(impl=CustomCollFB.class)
>>> public Collection 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 br
>> @Field(bridge=@FieldBridge(impl=CustomCollFB.class)
>> public Collection 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 ins
2011/8/1 Emmanuel Bernard :
>
> On 1 août 2011, at 10:31, Sanne Grinovero wrote:
>
>> 2011/8/1 Emmanuel Bernard :
>>>
>>> On 31 juil. 2011, at 21:44, Sanne Grinovero wrote:
>>>
@ElementCollection
@Field(indexNullAsl="nullToken")
String[] tags
>>>
>>> Hum is it really the way we are g
On 1 août 2011, at 10:31, Sanne Grinovero wrote:
> 2011/8/1 Emmanuel Bernard :
>>
>> 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
2011/8/1 Emmanuel Bernard :
>
> 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
On Mon, 01 Aug 2011 09:41:05 +0200, Emmanuel Bernard
wrote:
> We're back to the same problem over and over but to me the best mapping
> in Java 8 will be:
>
> @ElementCollection
> Collection<@Field(bridge=StringBridge.class) String> tags
right. same for HV and the ability to specify constrai
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 bre
On Sun, 31 Jul 2011 21:44:13 +0200, Sanne Grinovero
wrote:
> In case you would have a
>
> @ElementCollection
> @Field(indexNullAsl="nullToken")
> String[] tags
>
> having the value {"A","B",null}
>
> I would expect this to be encoded in the index with three field
> writes, all named "tags", an
Hello,
initially we dealt with null values as by not indexing them; since we
have the "indexNullAs" option on @Field [1]
we allow to use a custom token in the index instead, so to make it
possible to search for entities having that field at null.
In case you would have a
@ElementCollection
@Field
13 matches
Mail list logo
