ayushtkn commented on code in PR #6581:
URL: https://github.com/apache/hive/pull/6581#discussion_r3618838641
##########
ql/src/java/org/apache/hadoop/hive/ql/udf/esri/ST_NumGeometries.java:
##########
@@ -61,18 +58,10 @@ public IntWritable evaluate(BytesWritable geomref) {
case ST_POLYGON:
LogUtils.Log_InvalidType(LOG, GeometryUtils.OGCType.ST_MULTIPOLYGON,
ogcType);
Review Comment:
The contract here is that `ST_NumGeometries` is defined only for multi-part
types; a single type is treated as an argument error -> `NULL` plus a logged
message. That's pre-existing behaviour, unchanged by this patch, and it's
pinned by geospatial_udfs.q.out: the `POLYGON / LINESTRING / POINT` rows all
show `NULL`, while `MULTIPOLYGON -> 2, MULTIPOINT -> 4, MULTILINESTRING -> 2`.
Good instinct that a return 1 belongs somewhere, though — one did exist on
master, for a different path:
```
} catch (ClassCastException cce) { // single vs Multi geometry type
resultInt.set(1);
```
That fired when the type byte in the header said "multi" but the
deserialized Esri object wasn't, so the (`OGCMultiPoint`) cast blew up. It's
gone in the JTS version because it's no longer needed:
`default: geom.getNumGeometries()` covers every multi type and that mismatch
uniformly, since JTS returns 1 for a single geometry. Same effective behaviour,
without exception-driven control flow.
So making the flagged cases return 1 means deleting them and letting
everything fall through to `default:` a deliberate user-visible semantic change
that I'd rather not fold into a library swap. `PostGIS` made exactly that
change in 2.0 (returns `1` for single geometries, `NULL` only for non-geometry
input), so there's a reasonable case for it, happy to file a follow-up JIRA if
you agree.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
