[
https://issues.apache.org/jira/browse/CALCITE-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817551#comment-17817551
]
Julian Hyde commented on CALCITE-6263:
--------------------------------------
I don't mind Calcite having *some* coupling to JTS, but there shouldn't be too
much. An increase of coupling happens gradually, and in this case, I was
alerted by the fact that an import was added to {{class
RelDataTypeFactoryImpl}}, a key Calcite class.
There is a good argument (I don't recall whether a Jira case was logged) that
the geospatial functions should be in a separate module, and should be
available only when that module is on the class path and {{fun=spatial}} is on
the connect string. Not because we don't like spatial functions, but because
some people want to embed a more minimal Calcite.
In that scenario, should there be a built-in {{GEOMETRY}} type? I think yes.
But would you be able to do anything with values of type {{GEOMETRY}}? No, not
much, besides test whether they are null, because the core module would not
include JTS.
This may seem like Solomon cutting the baby in half just to prove a point. But
there is value in Calcite being able to parse, prepare and plan a query that it
cannot optimize.
There is a reasonable scenario where {{GEOMETRY}} values are represented as WKT
strings, enter from a JDBC source as WKT strings, and leave as WKT strings. In
a pass-through scenario like the one that motived CALCITE-6239, converting the
{{GEOMETRY}} values to JTS objects and then converting them back to strings is
actually less efficient. What if WKT were the default format for {{GEOMETRY}}
values?
This would not be the first time that Calcite has chosen the efficient
representation. ('Efficient' here meaning using very little memory, and
minimizing the CPU cost of deserializing values from the producer and
serializing values to the consumer.) In enumerable convention, {{DATE}} values
are represented as Java {{int}} values (or {{java.lang.Integer}} values if
nullable) rather than {{java.sql.Date}}.
If we did that, then the {{clazz}} field in {{RelDataTypeFactoryImpl.JavaType}}
would hold the value {{String.class}} not {{Geometry.class}}.
> Discuss the coupling of Calcite with JTS
> ----------------------------------------
>
> Key: CALCITE-6263
> URL: https://issues.apache.org/jira/browse/CALCITE-6263
> Project: Calcite
> Issue Type: New Feature
> Components: jdbc-adapter
> Reporter: Bertil Chapuis
> Priority: Major
>
> In order to push ST functions down to Postgis in the JDBC adapter, it is
> necessary to register a type family for geometries in
> [RelDataTypeFactoryImpl.java|https://github.com/apache/calcite/pull/3668/files#diff-0fa7bd8b0354c8a4c331efa4107242e49c5d521f31adbb71388bcbc9acb7a384].
> This changes increases the coupling of Calcite to a geometry library such as
> JTS.
> As this is an architectural change, a few options can be considered:
> # Accepting the coupling of Calcite with JTS.
> # Introducing an abstraction for geometry libraries in Calcite.
> # Using reflection to register the type family only if JTS is available in
> the classpath.
> Personally, I have a preference for options 1 and 3. Option 3, which is
> currently implemented in
> [CALCITE-6239|https://github.com/apache/calcite/pull/3668] has little impact
> on the current behavior. Option 2 would introduce some additional complexity.
> For context, here is a
> [link|https://github.com/apache/calcite/pull/3668#discussion_r1486925458] to
> the original discussion.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
