Open
Conversation
Client V2 CoverageCoverage Report
Class Coverage
|
JDBC V2 CoverageCoverage Report
Class Coverage
|
JDBC V1 CoverageCoverage Report
Class Coverage
|
Client V1 CoverageCoverage Report
Class Coverage
|
Member
|
@claude[agent] review changes |
Code Review: Geometry Type SupportI've reviewed the changes implementing Geometry alias type support. Here are my findings: SummaryThis PR adds support for ClickHouse's
FindingsCRITICAL: Missing null handling in array dimension detectionLocation: The
Impact: NPE risk if null values are passed, especially in the Recommendation: Add explicit null checks at the beginning of both methods. MEDIUM: Inconsistent type mapping between read and write pathsLocation: The map.put(1, getVariantOrdNum(column.nested, ClickHouseDataType.Point));
map.put(2, getVariantOrdNum(column.nested, ClickHouseDataType.Ring));
map.put(3, getVariantOrdNum(column.nested, ClickHouseDataType.Polygon));
map.put(4, getVariantOrdNum(column.nested, ClickHouseDataType.MultiPolygon));However, the underlying variant definition includes 6 types: Question: How do users write
Impact: Users cannot explicitly write LineString or MultiLineString geometries. The type is always inferred as Ring or Polygon for 2D/3D arrays respectively. Recommendation: Document this limitation or add a way to specify the exact geometry type (e.g., through wrapper objects). MEDIUM: Geometry type handling assumes double arraysLocation: The fast path checks explicitly for if (value instanceof double[] || value instanceof Double[]) {
return 1;
}This is correct for ClickHouse geometry types (which use Float64 = Double), but the error messages and the fallback to generic array dimension counting could be confusing if a user passes Impact: Error messages won't clearly explain why Recommendation: Consider adding validation that rejects non-double array types with a clearer error message. LOW: Inconsistent raw cast warningsLocation: Added Question: Is this suppression related to your changes, or was it accidentally included? LOW: Code duplication in DataTypeConverterLocation: The
Impact: Maintenance burden - bug fixes need to be applied twice. Recommendation: Consider extracting to a shared utility class or referencing one implementation from the other. LOW: String formatting for Geometry valuesLocation: The Question: Is this output format stable and intentional? It differs from standard geometric formats like WKT (Well-Known Text). If this is part of the user-visible API (getString() in JDBC), it should be documented as the canonical textual representation. Impact: Users may depend on this format for parsing or display. Compatibility Assessment✅ No breaking changes detected The changes are additive:
Test Coverage✅ Good coverage for read/write operations
Documentation
Final AssessmentSummary: The implementation is functionally correct for the common case (double arrays of 1-4 dimensions) and integrates well with the existing variant-type infrastructure. The main concerns are around null safety, the limitation of dimension-based type inference, and missing documentation. Compatibility risk: Low - changes are additive and follow existing patterns. Tests: Core read/write paths are tested. Edge cases and error paths need coverage. Docs: Should update Recommended actions before merge:
|
Claude
AI
changed the title
chernser
changed the title
Contributor
Author
|
@claude review |
|
Claude finished @chernser's task in 5m 31s —— View job Code Review: Geometry Type SupportTasks:
Review FindingsOrdered by severity, focusing on bugs, regressions, and compatibility risk. Bug: NPE in
|
|
Contributor
Author
|
@claude review |
|
Claude finished @chernser's task in 4m 37s —— View job Code Review: Geometry Type SupportTasks:
Status of Previous FindingsIssues from the two prior reviews were largely addressed:
FindingsMedium: Point element validation is more permissive in the write path than in the string path — inconsistent behavior across round-tripWrite path — return getGeometryLength(value) == 2
&& getGeometryElement(value, 0) instanceof Number
&& getGeometryElement(value, 1) instanceof Number;String path — return Array.getLength(value) == 2
&& Array.get(value, 0) instanceof Double
&& Array.get(value, 1) instanceof Double;The write path accepts any The string path requires boxed Recommendation: Align Medium:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
ClickHouse supports many geometry types like Point, Ring, Polygon and others (https://clickhouse.com/docs/sql-reference/data-types/geo). There was an alias type
Geometrythat pointed to aStringtype. When this type is used it was replaced byString. This very well works with WKT functions (https://clickhouse.com/blog/state-of-geospatial-march-2026#ingesting-geospatial-data-via-wkt) that can parse different geometry notations.When
Varianttype was introduced it made possible to have better type alias so in25.11Geometrytype became a real type not an alias. This doesn't break backward compatibility becauseStringwhen table was created. However today cast to Geometry means different thing.Varianttype ofGeometryhas a predefined list of types. Because of this we can pre-define column of such type and use it in serialization logic (client code usesClickHouseColumnobject to define how value should be serialized and deserialized). ReadingGeometrytype is easy task because we client matches type ordinary number to java type. Here we should note thatRingandLineStringareArray(Point)making them effectively same from data structure standpoint. Similar withMultiLineStringandPolygonare defined asArray(LineString)andArray(Ring)respectively. This make type inference on a write operation complicated because task is to match array with specific nesting level to a type and use correct ordinary number.There should be a dedicated method to determine java array depth. Similar should exist for
List. These only type client support to be written to geometry types. Because we deal with limited number of array types it is more safe to useinstanceof Double[]like statement instead of traversing whole array that can be quite big. In the future we will introduce some type hinting mechanism with annotations to make interface for type-safe.This PR:
ClickHouseDataTypeenumGeometryVariantdefined column toClickHouseColumnand implement readingGeometrycolumns definitions.SerializationUtilsCloses: #2678