[hibernate-dev] @Spatials

[Emmanuel Bernard]

On 4 juin 2012, at 17:03, Hardy Ferentschik wrote:

> 
> 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.

There are a few issues. @Spatial stands on its own and does not need @Field. @NumericField is a complement to @Field

    @Field(name="foo") @NumericField(forField="foo")

You can't model @Spatial like that because it's not attached to a given field. Plus most @Field properties do not apply.

There is an expectation that @Field maps to a Lucene field. We twisted that with custom field but you have to agree that this is not the common usage.
Also not that @Spatial can cross several java properties - or will in the near future. You will be able to mark properties as latitude or longitude for a given
spatial indexing.

I think the real reason I don't like @SpatialValue is because most of what we do is about value. No point putting it in a name.

Emmanuel