HyukjinKwon opened a new pull request, #281: URL: https://github.com/apache/spark-connect-rust/pull/281
### What changes were proposed in this pull request? [SPARK-61080](https://issues.apache.org/jira/browse/SPARK-61080): the data types now have the attributes, the `typeName` and the singletons of PySpark's types. - The types have the attributes of their parameters: - `StringType("UTF8_LCASE").collation` - `CharType(3).length` and `VarcharType(4).length` - `TimeType(3).precision` - the `startField` and `endField` of `DayTimeIntervalType` and `YearMonthIntervalType` - `DecimalType(10, 2).hasPrecisionInfo` - `typeName` is a classmethod, as PySpark's: `IntegerType.typeName()` is `integer`, the name of the class without `Type`, lowercased. The same holds for a subclass of `DataType`. The exceptions are PySpark's `void`, `timestamp_ntz` and `interval` for `NullType`, `TimestampNTZType` and `CalendarIntervalType`. - `StructField.typeName()` raises the `PySparkTypeError` `INVALID_TYPENAME_CALL`. - The types of PySpark's `DataTypeSingleton` are singletons: `IntegerType() is IntegerType()`. They are `NullType`, the integral types, `FloatType`, `DoubleType`, `BinaryType`, `BooleanType`, `DateType`, `TimestampType`, `TimestampNTZType` and `CalendarIntervalType`. The client also uses these instances for the types it builds from schemas and from their JSON. PySpark Connect, by contrast, unpickles a copy of the cached schema in `df.schema`, so the types there are new objects. This PR is on top of #277 ([SPARK-61075](https://issues.apache.org/jira/browse/SPARK-61075)), which is on top of #276 ([SPARK-61074](https://issues.apache.org/jira/browse/SPARK-61074)), as all three change the methods of each type class in `crates/pyspark-rs/src/types.rs`. It includes their commits until they merge, and its own change is the last commit. ### Why are the changes needed? - The client lacked these attributes: `StringType("UTF8_LCASE").collation` raised an `AttributeError`. - `typeName` was an instance method, so `IntegerType.typeName()` raised a `TypeError`. - `CalendarIntervalType().typeName()` was `calendarinterval`, not `interval`. - `StructField.typeName()` raised a plain `TypeError`. - Each call of a type class returned a new object. ### Does this PR introduce _any_ user-facing change? Yes. The types have the attributes, the type names and the singletons of PySpark 4.3.0. ### How was this patch tested? - A new live test checks the attributes of the types of a schema of the server: a collated string, an interval, a time and a decimal. It passes with official PySpark 4.3.0 and fails without this change. - A new offline test checks the attributes, the `typeName` of the classes, including an abstract one and a subclass of `DataType`, the error of `StructField.typeName`, and the singletons. - The `typeName` of 37 classes, a type API sweep of 48 cases, and the public attributes of 28 type classes are the same as official PySpark 4.3.0's. - The lib tests of both crates (592 passed), the build of all tests, also with `wasm-udf`, the offline Python suites (2018 passed, 8 skipped), and the live drop-in and Arrow suites (144 passed) and live cases (10 passed) against a local Spark 4.3.0 server. Clippy reports no diagnostics in the changed lines. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Opus 5.5 This pull request and its description were written by Isaac. -- 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]
