[
https://issues.apache.org/jira/browse/CALCITE-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817689#comment-17817689
]
Bertil Chapuis commented on CALCITE-6263:
-----------------------------------------
Quick question, what would you think about introducing wrapper for the geometry
type? For instance:
{code:java}
/**
* Wrapper for geometry objects.
*/
public class GeometryWrapper {
private final Object geometry;
public GeometryWrapper(Object geometry) {
this.geometry = geometry;
}
public Object getGeometry() {
return geometry;
}
}{code}
{code:java}
private static final Map<Class, RelDataTypeFamily> CLASS_FAMILIES =
ImmutableMap.<Class, RelDataTypeFamily>builder()
.put(String.class, SqlTypeFamily.CHARACTER)
//...
.put(GeometryWrapper.class, SqlTypeFamily.GEO)
.build(); {code}
This would mean that all functions dealing with geometries would have to accept
the wrapper, and deal with the wrapping/unwrapping of the value. For instance:
{code:java}
public static Geometry ST_Point(BigDecimal x, BigDecimal y) {
return GEOMETRY_FACTORY.createPoint(new Coordinate(x.doubleValue(),
y.doubleValue()));
} {code}
Would become:
{code:java}
public static GeometryWrapper ST_Point(BigDecimal x, BigDecimal y) {
return new GeometryWrapper(GEOMETRY_FACTORY.createPoint(new
Coordinate(x.doubleValue(), y.doubleValue())));
} {code}
> 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)
