Re: [hibernate-dev] @Spatials
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