On 08 Sep 2015, at 22:29, Steve Ebersole <steve(a)hibernate.org>
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.
Yes, precisely that
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
It is true that not all applications use spatial, or even that DB’s support (all) spatial
functions. But it would help to ensure consistency in the available dialects. Now this
consistency is tested for in the integration tests, so not having this at the grammar
isn’t a big problem.
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?
W.r.t operators: don’t the same concern about not all applications using spatial apply
here as well? In any case, I don’t think operators are going to be popular. Just about
everyone is happy to use the relevant spatial relationship functions. At least their names
and semantics are pretty standard across implementations and technologies. There is to my
knowledge no comparable standard for spatial symbolic operators.
Support for spatial literals would be a great plus. In my opinion, the best candidate for
HQL spatial literals is the Postgis EWKT format
), which is a
sane, and popular extension of the purely 2D WKT standard. It is supported in the
geolatte-geom library and many others. I can help by writing a grammar for this.
There is also at least one HQL syntax change that would help implement spatial functions:
function invocations that evaluate to boolean should be regarded as valid boolean
expressions. The HQL currently doesn’t seem to allow this, so I needed to wrap them in
equality expressions. But then MySQL wouldn’t use its spatial index (as I wrote before,
although I mistakenly wrote “spatial query” in my original email).