The default name for @Spatial is the empty string (at least as defined
on the annotation before we override it to the entity mode).
Considering we have @Spatials (plural) to support multiple coordinates
on a single entity, would it make sense to support
onCoordinates(String... names)
?
This has the nice effect of supporting the method without any
parameter, so one can use
Query luceneQuery = builder.spatial()
.onCoordinates()
.within( 50, Unit.KM )
...
to point to the default one (undefined, aka empty string)
Can also target multiple constraints at once:
Query luceneQuery = builder.spatial()
.onCoordinates( "home", "office" )
.within( 50, Unit.KM )
...
Looks not so good when mixing default and specific:
Query luceneQuery = builder.spatial()
.onCoordinates( "", "office" )
.within( 50, Unit.KM )
...
But my guess is that when having multiple coordinates on an entity it
should be recommended to name them all explicitly; we could even
require this.
--
+1 to not consider
"SpatialQueryBuilder.buildSpatialQueryByGrid" a public API but in that
case I think we should update the tests using it to use the DSL.
Sanne
On 10 October 2012 08:44, Nicolas Helleringer
<nicolas.hellerin...@gmail.com> wrote:
> 5 seems just fine to me
>
> Niko
>
> 2012/10/10 Emmanuel Bernard <emman...@hibernate.org>
>>
>> I see a few options:
>>
>> 1. Make onCoordinates optional
>>
>> For me that does not look right and would make the dsl confusing but I'd
>> like to see additional feedback
>>
>> 2. Use a constant
>>
>> .onCoordinates(Statial.DEFAULT_COORDINATES_PROPERTY)
>>
>> 3. Use the class name ( that's what you did )
>>
>> 4. Use "" as the value
>>
>> .onCoordinates("")
>>
>> 5. Add a specific method
>>
>> .onDefaultCoordinates()
>>
>> So far 5 seems the most natural to me.
>>
>> Emmanuel
>>
>>
>> On 10 oct. 2012, at 09:20, Nicolas Helleringer
>> <nicolas.hellerin...@gmail.com> wrote:
>>
>> This makes sense.
>> The DSL is clearly THE way to build spatial queries. It simple and
>> elegant.
>>
>> By the way, Emmanuel, I would like some help to remove the
>> .onCoordinates( PoI.class.getName() )
>>
>> in
>>
>> Query luceneQuery = builder.spatial()
>> .onCoordinates( PoI.class.getName() )
>> .within( 50, Unit.KM )
>> .ofLatitude( centerLatitude )
>> .andLongitude( centerLongitude )
>> .createQuery();
>>
>> when building a spatial query on a class with a @Spatial that does not
>> have a name attribute set and thus using the default value of
>> class.getName()
>>
>> Niko
>>
>>
>> 2012/10/10 Emmanuel Bernard <emman...@hibernate.org>
>>>
>>> I almost think that org.hibernate.search.spatial.SpatialQueryBuilder
>>> should be an internal class. Do we want to offer direct access to these
>>> instead of the dsl?
>>> The answer could be yes, but I'd like to see a use case.
>>>
>>> On 9 oct. 2012, at 18:45, Sanne Grinovero <sa...@hibernate.org> wrote:
>>>
>>> > Hi Nicolas,
>>> >
>>> > In the QueryBuilder DSL a spatial Query has a nice option to define
>>> > which units are being used:
>>> >
>>> > org.apache.lucene.search.Query luceneQuery =
>>> > builder.spatial().onCoordinates( UserRange.class.getName() )
>>> > .within( 50, Unit.KM ).ofLatitude( centerLatitude
>>> > ).andLongitude(
>>> > centerLongitude ).createQuery();
>>> >
>>> >
>>> >
>>> > org.hibernate.search.spatial.SpatialQueryBuilder.buildSpatialQueryByGrid(double,
>>> > double, double, String)
>>> > has a javadoc comment specifying the parameters are expected to be KM.
>>> >
>>> > I guess we should pick a strategy and be consistent with it; I think
>>> > we should add the Unit parameter to the SpatialQueryBuilder;
>>> >
>>> > Any thoughts about it? Can I assume you'll be able to look into that?
>>> >
>>> > Cheers,
>>> > Sanne
>>> >
>>> > Tracked by https://hibernate.onjira.com/browse/HSEARCH-1203
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev@lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
