[hibernate-dev] HQL and spatial

[Steve Ebersole]

What do you mean "have these functions integrated into HQL"?  What you
describe is exactly how sql functions are supported as well.  Perhaps you
mean defining standard support for spatial functions.  As a corollary, take
something like the ANSI SQL TRIM function.  Not all databases support TRIM
as defined by ANSI SQL so ultimately we leverage Dialect registered support
for what the database does support.  However, we encode "TRIM support" into
the HQL grammar (in the rewrite) to make sure that the arguments are
handled consistently.  We do still expect each that the Dialect as
registered an appropriate SQLFunction representation of its TRIM function
support.  We could do something like that here as well.  The main
difference is that not all applications are using spatial.

So more I am asking about syntax changes that might help support spatial
queries, specific operators, etc.  How about declaring "spatial literals"?
Does that make sense for spatial queries?



On Wed, Sep 2, 2015 at 12:29 PM Karel Maesen <karel at geovise.com> wrote:

> Hi Steve,
>
> Have a look at this table:
> http://www.hibernatespatial.org/documentation/03-dialects/01-overview/
>
> It provides an overview of the HQL functions that are supported in
> Hibernate Spatial. They are  currently registered into each concrete
> SpatialDialect. I think it might be a good start to start having these
> functions integrated into HQL.
>
> These functions are commonly found in spatial databases because they have
> been defined in the Simple Feature Specification (SFS). The reference given
> after each function refers to this spec. This spec was originally intended
> to be used only for planar 2D geometries, but has been extended by most
> databases to apply also to 3D/4D and non-planer, i.e. geographic
> coordinates.
>
> There is also the 'SQL/MM, Part 3' - Spatial specification. This spec is,
> as I understand it, derived from the Simple Feature Specification but adds
> support for more complicated geometries and for 3D/4D geometries. Not all
> databases have support for everything specified in there, and no
> open-source Java geometry library has either.
>
> As for implementation, there are some weird cases.  For example, if you
> specify in MySQL (native SQL)  "select * from t where st_contains(geom1,
> geom2) = 1” the spatial query is not used, but it is used when the
> statement reads "select * from t where st_contains(geom1, geom2)”. Both
> should be equivalent.
>
> Another example. In Oracle10g the HQL spatial functions are translated to
> something like this:  "SELECT A.Feature_ID FROM TARGET A WHERE
> sdo_filter(A.shape, :theWindow,'querytype=window') = 'TRUE’;”
>
> The whole and only the whole expression ‘sdo_filter(...) = ‘TRUE’’
> evaluates to TRUE. So leaving the “... = ‘TRUE’” part off or putting
> something else in there, fails to evaluate.
>
> Hope this helps kick off the discussion.
>
> Regards,
>
> Karel
>
>
>
>
> > On 26 Aug 2015, at 05:20, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > Karel, etal
> >
> > We have discussed spatial-specific extensions to HQL for quite some time.
> > But those discussions have always been kind of esoteric ("boy wouldn't it
> > be nice to have some spatial support in HQL").
> >
> > As we are working on redesigning the parsing and interpretation of HQL
> > queries and since spatial has been integrated upstream, it seems like a
> > great time to discuss specifics of what this might mean.
> >
> > I have never used spatial data, let alone crafted queries using spatial
> > data.  So I am not the best driver here.
> >
> > What kinds of things make sense to add to HQL for supporting spatial
> > queries?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>