3:44 p.m.
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(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", and having values "A", "B",
"nullToken".
But what if the array value is null by itself?
Personally I would expect it to *not* write anything, not encode the
"nullToken" which is reserved for an element being null: not having
the collection itself means in my opinion that there are no elements,
being similar as having an empty collection.
An alternative way could be to write the "nullToken" in both cases,
but I'm not liking this much as it would imply that the item will
match for a search similar to "all items having a null tag", while in
fact it had no tags at all.
I'd avoid adding more options as it would need a new annotation, or
adding options to other annotations which only apply in this case.
What do others think?
Sanne
1 -
http://docs.jboss.org/hibernate/search/3.4/api/org/hibernate/search/annot...
3:07 a.m.
On Sun, 31 Jul 2011 21:44:13 +0200, Sanne Grinovero <sanne(a)hibernate.org>
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", and having values "A", "B",
"nullToken".
+1
But what if the array value is null by itself?
Personally I would expect it to *not* write anything, not encode the
"nullToken" which is reserved for an element being null: not having
the collection itself means in my opinion that there are no elements,
being similar as having an empty collection.
+1
I think in combination w/ @ElementCollection the @Fiels annotations tells
you what do to with the elements of the array/collection not the
array/collection
itself.
An alternative way could be to write the "nullToken" in
both cases,
but I'm not liking this much as it would imply that the item will
match for a search similar to "all items having a null tag", while in
fact it had no tags at all.
I don't like this approach either.
I'd avoid adding more options as it would need a new annotation,
or
adding options to other annotations which only apply in this case.
What do others think?
Are you talking about some sort of @ElelemntCollectionField (w/ the same
semantics as
@Field, but limited for the usecase of element collections?
Adding such an annotation would reduce ambiguities imo, but of course
there would be
one more annotation. Are there any other disadvantages?
--Hardy
3:41 a.m.
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
We're back to the same problem over and over but to me the best mapping in Java 8 will
be:
@ElementCollection
Collection<(a)Field(bridge=StringBridge.class) String> tags
But until then we need to find alternatives. I can see two alternatives
1. use a custom @ElementField annotation
This annotation will represent the element in a collection.
I like this idea as it forward compatible with Java 8's approach
2. Let @Field be used for elements of a collection and create a @CollectionField to index
the collection
Subsidiary questions:
- is there other annotation that need to be converted to the @Element* pattern?
- what about maps and specifically keys in maps?
4:05 a.m.
On Mon, 01 Aug 2011 09:41:05 +0200, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
We're back to the same problem over and over but to me the best
mapping
in Java 8 will be:
@ElementCollection
Collection<(a)Field(bridge=StringBridge.class) String> tags
right. same for HV and the ability to specify constraints for the elements
of a "basic" collection.
But until then we need to find alternatives. I can see two
alternatives
1. use a custom @ElementField annotation
This annotation will represent the element in a collection.
I like this idea as it forward compatible with Java 8's approach
I like this best and that's what I meant w/ @ElementCollectionField, but
@ElementField is better
--Hardy
4:31 a.m.
2011/8/1 Emmanuel Bernard <emmanuel(a)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.
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.
5:57 a.m.
On 1 août 2011, at 10:31, Sanne Grinovero wrote:
2011/8/1 Emmanuel Bernard <emmanuel(a)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.
@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?
You would let people set a @Resolution and be applied to the elements?
## How about NumericField?
Same as @Resolution?
## 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.
6:27 a.m.
2011/8/1 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 1 août 2011, at 10:31, Sanne Grinovero wrote:
> 2011/8/1 Emmanuel Bernard <emmanuel(a)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=(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?
## 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?
6:48 a.m.
> @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
7:01 a.m.
2011/8/1 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>> @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.
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
7:53 a.m.
On Mon, 01 Aug 2011 13:01:02 +0200, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
>> @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.
I back up Emmanuel's comment about potential confusion. I don't think
adding
a @CollectionField is such an overhead and it could have nested parameters
for
things like @Reolution, etc
> @IndexedEmbedded
> @DateBridge(resolution=Resolution.DAY)
> private Set<Date> 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?
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.
--Hardy
8:04 a.m.
>> @IndexedEmbedded
>> @DateBridge(resolution=Resolution.DAY)
>> private Set<Date> 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?
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.
Note that @ElementCollection is the JPA annotation that might or might not be present
(HSearch on Infinispan doesn't use JPA annotations).
My reasoning for liking @IndexedEmbedded is that whether basic, embeddable or entity
collection, it's still a collection and we still embed the information into the
index.
8:26 a.m.
On Mon, 01 Aug 2011 14:04:58 +0200, Emmanuel Bernard
<emmanuel(a)hibernate.org> 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)
--Hardy
8:09 a.m.
[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 annotations. I was considering
Emmanuel's suggestion to replace the need for any @Element*
annotation, but I see now that's my interpretation only. Emmanuel?
What's the ambiguity you're thinking off? the only controversial thing
I might see is the fact we would likely strip off the prefix in this
case.
Sanne
4651
days inactive
4652
days old
12 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Hardy Ferentschik -
Sanne Grinovero