Hi all, I'm working on the programatic mapping of HSEARCH-923 (spatial support) and I had to implements @Spatials for @Spatial as @Fields is to @Field Emmanuel checked my work on my gtihub repo and some questions raised we would like to share with you : - Is @Spatials the right name for such a property ? It mimics @Fields but it does not feels right. Emmanuel proposes @Spatial.List (which I am not fond of, sorry) but it is against Hibernate coding habits

- @Spatial is supported at entity level and at property level. But if it seems ok for an entity to have multiples location  through @Spatials (think a user with a work and a personnal address/position) it seems more weird to have @Spatials at property level. The only use case I see is having a Coordinate property indexed in different ways by having different parameters sets for each @Spatial instance. What do you think ? Niko PS : working branch is here https://github.com/nicolashelleringer/hibernate-search/tree/progmap _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Without looking into the issue closer I like @SpatialValue also better. It seems more descriptive. Regarding @Spatials, I think @Spatial.List or even better @SpatialValue.List not too bad. the .List approach is the one taken in Bean Validation as well and @SpatialValue.List does not sound bad imo. --Hardy On Jun 1, 2012, at 5:03 PM, Sanne Grinovero wrote: > On 1 June 2012 14:49, Nicolas Helleringer <nicolas.helleringer(a)gmail.com&gt; wrote: >> Hi all, >> >> I'm working on the programatic mapping of HSEARCH-923 (spatial support) and >> I had to implements @Spatials for >> @Spatial as @Fields is to @Field >> >> Emmanuel checked my work on my gtihub repo and some questions raised we >> would like to share with you : >> >> - Is @Spatials the right name for such a property ? It mimics @Fields but >> it does not feels right. >> Emmanuel proposes @Spatial.List (which I am not fond of, sorry) but it is >> against Hibernate coding habits > > Literally with a "." dot in the middle of the annotation? > > Besides, I don't like the "Spatial" name at all when applied to a > field/property. It is a good name for the concept, and could make a > good modifier, but in my interpretation it doesn't associate with an > entity attribute. > > @SpatialValue ? > > But consider my opinion worth less than the traditional 2cents as I > have no experience with spatial technology, so my interpretation might > be far off than what people of the field might be used to deal with. > > >> - @Spatial is supported at entity level and at property level. But if it >> seems ok for an entity to have multiples location >> through @Spatials (think a user with a work and a personnal >> address/position) it seems more weird to have @Spatials >> at property level. >> The only use case I see is having a Coordinate property indexed in >> different ways by having different >> parameters sets for each @Spatial instance. >> >> What do you think ? >> >> Niko >> >> PS : working branch is here >> https://github.com/nicolashelleringer/hibernate-search/tree/progmap >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On Jun 4, 2012, at 4:51 PM, Emmanuel Bernard wrote: > I don't think it can be SpatialValue as the annotations: > > - marks the property describing the spatial coordinates > - describes how the data will be indexed wrt spatial indexing (strategy + fine tuning) > - describes the usual boost, etc properties I don't see a contradiction between these points and @SpatialValue (at least w/ my current understanding of the feature) > It's the sister of @Field but @SpatialField is wrong as we are not storing data in one field but several. Hmm, I would like the symmetry between @Field, @NumericField and @SpatialField. is it really a concern that we are storing data into multiple fields. I don't think there is an expectation for a one to one mapping between @Field and the Lucene index. Using a custom field bridge any user can for example index a single property into multiple Document fields. From this perspective @SpatialField just implies a special field bridge which creates multiple Document fields. This would fit fine into my model on how Search works.