Skip to content

add a way to exclude a column from schema validation#816

Draft
gavinking wants to merge 1 commit intojakartaee:mainfrom
gavinking:column-validated
Draft

add a way to exclude a column from schema validation#816
gavinking wants to merge 1 commit intojakartaee:mainfrom
gavinking:column-validated

Conversation

@gavinking
Copy link
Member

Sometimes users run into a case where the schema validation is too strict, and their program actually works as is; it's nice to have a way to exclude a column from validation.

Fixes #815.

WDYT?

@gavinking gavinking force-pushed the column-validated branch 4 times, most recently from 2800fbc to 7770576 Compare December 13, 2025 15:31
@gavinking gavinking changed the base branch from master to main December 15, 2025 19:55
Comment on lines +191 to +195
* Determines if this column is validated as part of the
* schema {@linkplain SchemaManager#validate validation}
* process. By default, the column is validated. If the
* column should be excluded from validation, specify
* {@code validated=false}.
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is an important ambiguity here. What does "excluded from validation" mean precisely? Does it mean we check that the column exists but perform no further validation beyond that? Or does it mean we don't even validate that it exists in the table? 🤔

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't imagine a situation where one would want their program to run against a database where one of the column doesn't exists... ?

The original use case was to workaround limitations in validation type-checking. So I think we want that:

we check that the column exists but perform no further validation beyond that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's probably right.

sometimes users run into a case where the schema validation
is too strict, and their program actually works as is; it's
nice to have a way to exclude a column from validation

see jakartaee#815
Comment on lines +191 to +195
* Determines if this column is validated as part of the
* schema {@linkplain SchemaManager#validate validation}
* process. By default, the column is validated. If the
* column should be excluded from validation, specify
* {@code validated=false}.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't imagine a situation where one would want their program to run against a database where one of the column doesn't exists... ?

The original use case was to workaround limitations in validation type-checking. So I think we want that:

we check that the column exists but perform no further validation beyond that?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't validation also make sense for things that are not related to columns?

I couldn't find a precise definition of schema validation in the JPA spec, so I suppose it's up to the implementation to pick what gets validated.

I can see that there are a few more things than columns which could impact the schema:

  • @Table.uniqueConstraints
  • @Table.indexes
  • @Table.check

And maybe more but the rest seems... unlikely to be validated.

Maybe @Table.validated would make some sort of sense?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, yeah, in principle, but I'm cautious about adding features to the spec for some purely-speculative feature that some JPA implementation might have at some unspecified point in the future.

So unless we're making a decision to start validating the existence of constraints, I wouldn't add this.

That's not to say I don't think constraint validation would be useful. Just we don't have any implementation of it yet.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other side of the coin is that if we don't add it now, then when an implementation decides to implement such validation (since that's up to the implementation), there will likely be a delay of months, likely years, before the corresponding "validation" exclusion is made available for tables in the same way it is available for columns. Leading to either a gap in functionality, or the temporary introduction of native annotations -- which, for @Table at least, we've been trying to get rid of.

One way to circumvent your position would be to decree that validated = false on a table means both the table's constraints and its columns don't get validated (regardless of what's configured at the column level). Then the attribute would have a use right now.

Otherwise, okay, if it's a conscious decision, fair enough.

Copy link
Member Author

@gavinking gavinking Jan 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I can sorta see that validated=false is a reasonably natural way to say "don't validate the existence of columns". (Though we agree that's not especially useful.)

I'm not sure it's an especially good way to indicate that, say, a foreign key or unique key constraint should not be validated. I feel like that's something you would want to be able to set per-constraint, not once for the whole table.

Also note that @ForeignKey actually already has something pretty close to that with @ForeignKey(NO_CONSTRAINT). Ignore the particular syntax, which I've never liked.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

 * @since 2.1
 */
public enum ConstraintMode {

@since 2.1 is this massive red flag in the persistence APIs. 😭

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like that's something you would want to be able to set per-constraint, not once for the whole table.

True, but then the whole feature is a workaround to deal with false-positives of validation. Disabling validation of a specific constraint would be best, but failing that disabling validation of the whole table still has benefits (you can validate other tables).

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.

exclude column from schema validation

2 participants