[jira] [Updated] (CALCITE-6263) Discuss the coupling of Calcite with JTS

["Ruben Q L (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ruben Q L updated CALCITE-6263:
-------------------------------
    Fix Version/s:     (was: 1.41.0)

> 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)