2011/8/1 Emmanuel Bernard <emman...@hibernate.org>: > > On 1 août 2011, at 10:31, Sanne Grinovero wrote: > >> 2011/8/1 Emmanuel Bernard <emman...@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? _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev