Skip to content

[SPARK-55716][SQL][FOLLOWUP] Simplify NOT NULL preservation by skipping asNullable in resolveRelation#54597

Open
yaooqinn wants to merge 1 commit intoapache:masterfrom
yaooqinn:SPARK-55716
Open

[SPARK-55716][SQL][FOLLOWUP] Simplify NOT NULL preservation by skipping asNullable in resolveRelation#54597
yaooqinn wants to merge 1 commit intoapache:masterfrom
yaooqinn:SPARK-55716

Conversation

@yaooqinn
Copy link
Member

@yaooqinn yaooqinn commented Mar 3, 2026

What changes were proposed in this pull request?

Followup to #54517. Simplifies NOT NULL constraint preservation per review feedback.

Instead of calling dataSchema.asNullable in resolveRelation() and then restoring nullability with recursive restoreNullability/restoreDataTypeNullability helpers in CreateDataSourceTableCommand, this PR:

  1. Adds a forceNullable parameter to DataSource.resolveRelation() (default true, preserving existing behavior)
  2. Passes forceNullable = !enforceNotNull from CreateDataSourceTableCommand, so asNullable is skipped only when the config is enabled
  3. Removes restoreNullability and restoreDataTypeNullability helper methods entirely

Data flow:

  • Config OFF (default): forceNullable = trueasNullable runs → same behavior as before SPARK-55716
  • Config ON: forceNullable = falseasNullable skipped → catalog stores NOT NULL → PreprocessTableInsertion enforces at insert time

Why are the changes needed?

Addresses review feedback: "is it simpler to not do dataSchema.asNullable if the flag is on?"

Does this PR introduce any user-facing change?

No.

How was this patch tested?

Existing SPARK-55716 tests (7 tests in InsertSuite) and ShowCreateTableSuite (30 tests) all pass.

Was this patch authored or co-authored using generative AI tooling?

Yes, co-authored with GitHub Copilot.

…ng asNullable in resolveRelation

Instead of calling `dataSchema.asNullable` in `resolveRelation()` and then restoring nullability from the user schema in `CreateDataSourceTableCommand`, add a `forceNullable` parameter to `resolveRelation()` and pass `false` from the create-table path.

This eliminates the `restoreNullability` and `restoreDataTypeNullability` helper methods, simplifying the code significantly (-37 lines net).

The read path is unaffected: `resolveRelation()` defaults to `forceNullable = true` (preserving SPARK-13738 safety). Only the create-table path skips `asNullable` so the catalog stores the user's original nullability constraints.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant