On Sun, 31 Jul 2011 21:44:13 +0200, Sanne Grinovero <sa...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev