salimTutuncu opened a new issue, #927: URL: https://github.com/apache/incubator-xtable/issues/927
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/incubator-xtable/issues?q=is%3Aissue) and found no similar issues. ### Please describe the bug 🐞 ### Describe the bug The 0.4.0 release notes list the Parquet source "with partition extraction", and the core module implements it (`ParquetSourceConfig` / `ParquetPartitionSpecExtractor`, exercised directly by the core integration tests). However, the spark-runtime bundle, a shipped way to run 0.4.0 syncs, provides **no route to that configuration**: converting a Hive-style partitioned Parquet table through `XTableSparkSync` or `XTableSyncService` always produces an unpartitioned target. `--partitionspec` does not help, and per the CLI help and `TableSyncSpec` javadoc it is scoped to Hudi sources, so this is a missing-capability gap in the runtime rather than a broken flag. A secondary UX point: the CLI accepts `--partitionspec` together with `--sourceformat PARQUET` without any warning, which reads as if it applies; failing fast (or forwarding it) would remove the ambiguity. ### Root cause `XTableSyncService` forwards `TableSyncSpec.partitionSpec` using only the Hudi configuration key, for every source format: https://github.com/apache/incubator-xtable/blob/e8f22867a6cb297f58b248150220fce71188d16a/xtable-spark-runtime/src/main/java/org/apache/xtable/spark/XTableSyncService.java#L62-L65 ```java if (spec.getPartitionSpec() != null && !spec.getPartitionSpec().isEmpty()) { sourceProperties.put(HudiSourceConfig.PARTITION_FIELD_SPEC_CONFIG, spec.getPartitionSpec()); } ``` The Parquet source reads a different key, `xtable.parquet.source.partition_field_spec_config`, which nothing in the spark-runtime ever populates: https://github.com/apache/incubator-xtable/blob/e8f22867a6cb297f58b248150220fce71188d16a/xtable-core/src/main/java/org/apache/xtable/parquet/ParquetSourceConfig.java#L36-L74 Related but distinct: #901 covers the schema being derived from a single file footer, which independently drops directory-only partition columns for Spark-written (`partitionBy`) layouts. Wiring the configuration through is necessary but may not be sufficient for such layouts until #901 is addressed. ### To Reproduce To isolate this from #901 (footer-derived schema), the fixture keeps `order_date` **inside the Parquet files** while still using Hive-style partition directories: files are written directly into `order_date=2026-08-01/` without Spark's `partitionBy` (which would strip the column from the files). Reproduction scripts are included at the bottom of this issue. ```bash # 1. Hive-style layout, partition column RETAINED in the file schema spark-submit gen_parquet_keepcol.py /tmp/orders_parquet_kc # 2. sync, with and without the flag (same result) spark-submit --master 'local[2]' \ --class org.apache.xtable.spark.XTableSparkSync \ --jars iceberg-spark-runtime-3.5_2.12-1.9.2.jar \ xtable-spark-runtime_2.12-0.4.0-incubating.jar \ --basepath /tmp/orders_parquet_kc --sourceformat PARQUET --targets ICEBERG \ --partitionspec order_date:VALUE # 3. inspect spark-submit --jars iceberg-spark-runtime-3.5_2.12-1.9.2.jar \ inspect_iceberg.py /tmp/orders_parquet_kc --partitions ``` Observed: `order_date` **is present** in the target schema (so #901 is not in play for this fixture), yet the table has an empty partition spec and no partition values, identically with and without `--partitionspec`. For contrast, a Hudi source with the same flag on the same runtime produces a correctly partitioned target, confirming the flag transport works when the matching config key is written. ### Expected behavior The spark-runtime provides a way to configure Parquet source partitioning (e.g. forwarding the spec to the source-format-appropriate config key), so that the release-notes capability is reachable through the shipped runtime; and `--partitionspec` with a PARQUET source either applies or fails fast with a clear message. ### Affected versions `0.4.0-incubating` artifact; code verified identical on `branch-0.4` HEAD (the spark-runtime module does not exist on `main` at the time of filing). #### Reproduction scripts <details><summary>gen_parquet_keepcol.py</summary> ```python import sys from pyspark.sql import SparkSession, functions as F base = sys.argv[1] spark = SparkSession.builder.getOrCreate() for d, off in [("2026-08-01", 0), ("2026-08-02", 1000)]: (spark.range(off, off + 1000).withColumn("order_id", F.col("id")) .withColumn("order_date", F.lit(d)).drop("id").repartition(2) .write.mode("overwrite").parquet(f"{base}/order_date={d}")) # no partitionBy print("wrote 2000 rows across 2 partition dirs ->", base) ``` </details> <details><summary>inspect_iceberg.py</summary> ```python import sys from pyspark.sql import SparkSession, functions as F path = sys.argv[1] spark = SparkSession.builder.getOrCreate() df = spark.read.format("iceberg").load(path) print("optimized count(*) :", df.count()) print("forced distinct order_id:", df.select(F.countDistinct("order_id")).collect()[0][0]) print("columns :", df.columns) spark.read.format("iceberg").load(path + "#files") \ .select("file_path", "record_count", "value_counts").show(truncate=False) if "--partitions" in sys.argv: try: spark.read.format("iceberg").load(path + "#partitions").show(truncate=False) except Exception as e: print("partitions metadata unavailable:", type(e).__name__) ``` </details> ### Are you willing to submit PR? - [ ] I am willing to submit a PR! - [ ] I am willing to submit a PR but need help getting started! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- 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]
