DanielLeens commented on PR #11493: URL: https://github.com/apache/seatunnel/pull/11493#issuecomment-6592035529
@SEZ9 thanks. I checked each point against `925fb9c1fe0da5b6cd1b0a65b7fbcd036f22a16b`. F1 to F3 are documented where you asked; F4 is where I need to be honest about a bigger problem. - **F1 (opt-out on each affected source page).** `handle_json_as_string` is documented with the new type mapping in `docs/en` and `docs/zh` for the Doris source, the Jdbc source (only Snowflake `VARIANT` is mapped to `JSON`; other dialects are unaffected), and the Snowflake source, in addition to the incompatible-changes page. The StarRocks source has no inferred mapping to opt out of because it always uses the declared `schema`; its page says to declare the column as `string` to keep the old behavior. - **F2 (validity contract).** `schema-feature.md` (en and zh) now has a note under the `json` row: the type guarantees the representation only, and validity is enforced at the parsing boundaries (JSON format, StarRocks JSON Stream Load, Snowflake `PARSE_JSON` on the server). Every other sink passes the text through. - **F3 (StarRocks JSON with default CSV).** The StarRocks sink page in both languages says native `JSON` columns need `starrocks.config.format = "JSON"`, and that the sink rejects JSON columns with CSV at creation time. - **F4 (Snowflake user-defined query).** Current behavior: with JSON fields in the schema, a custom `query` is rejected at sink creation unless it contains `PARSE_JSON` (a case-insensitive text check), and the docs tell the user to wrap each JSON placeholder. That check is weak: it does not verify that every JSON bind is wrapped (Issue 9 in my last review, non-blocking). More important, and a miss from earlier rounds that I only caught in my last review: Snowflake does not allow `PARSE_JSON(...)` inside a `VALUES` clause. The generated insert (`SnowflakeDialect.java`, `VALUES (:id, PARSE_JSON(:payload))`), the unit test that asserts that string, and the docs example `INSERT ... VALUES (?, PARSE_JSON(?))` all use the unsupported shape. The form should be `INSERT INTO ... SELECT :id, PARSE_JSON(:payload)`, so the generated SQL, the docs example, and the test expectation all need to change. That has not been done on this head. Still open from the same review, also needing code: the Qdrant error construction fails with a unit failure (Issue 3), the StarRocks rejection IT still expects the old late-serializer message (Issue 8), and replacement checks for the dropped Doris length assertions (Issue 11). The branch is also currently `DIRTY` against `dev`, so a sync is needed along with these fixes. So this PR is not ready; I will address these in the next push and not claim a CI result until a run completes on that head. -- 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]
