[
https://issues.apache.org/jira/browse/CALCITE-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817623#comment-17817623
]
Bertil Chapuis commented on CALCITE-6263:
-----------------------------------------
Thank you very much for these clarifications. I understand the argument for
keeping RelDataTypeFactoryImpl clean and for maintaining a minimal Calcite. I
guess this clearly excludes options 1 and 3 described earlier.
I agree that moving the spatial functions to a dedicated submodule would be
great, and we should do it eventually. However, with CALCITE-6239, my goal was
to have a first working version as quickly as possible. Having the spatial
functions in the core helped a lot and was rather comfortable.
I'm not really in favor of representing geometries with strings due to the
impact on performance, and would prefer using a binary representation. The
choice of the format could eventually be left to the implementer. I will try to
investigate other means to add support for geometries without affecting
RelDataTypeFactoryImpl (extending it?) that have a lesser impact on the core
and come back with propositions.
As a side note, I guess this issue will also be of interest to those
implementing support for JSON types and functions in Calcite.
> 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)
