Skip to content

Replace attribute-to-attribute comparison with constant for cross-datastore portability#1327

Closed
otaviojava wants to merge 5 commits intomainfrom
update-number-page-constant
Closed

Replace attribute-to-attribute comparison with constant for cross-datastore portability#1327
otaviojava wants to merge 5 commits intomainfrom
update-number-page-constant

Conversation

@otaviojava
Copy link
Copy Markdown
Contributor

@otaviojava otaviojava commented Jan 15, 2026

This change replaces an attribute-to-attribute comparison in a Jakarta Query predicate with a constant value.

While the original expression works in SQL, it is not reliably supported across NoSQL providers and may bypass indexes or trigger full scans.

Using a constant ensures consistent semantics, predictable performance, and portability across SQL and NoSQL implementations.

@otaviojava otaviojava requested a review from njr-11 January 15, 2026 17:37
Copy link
Copy Markdown
Member

@njr-11 njr-11 left a comment

Choose a reason for hiding this comment

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

While the original expression works in SQL, it is not reliably supported across NoSQL providers and may bypass indexes or trigger full scans.

The test is not written to use SQL. It is written to rely on JCQL, which allows the pattern,

comparison_expression : scalar_expression comparison_operator scalar_expression;

As currently written, the Jakarta Data spec allows Key-Value and Wide-Column to raise UnsupportedOperationException, and those two database types are exactly what the TCK test checks for and skips the test already. If there are additional allowances needed for Document and/or Graph, please let me know, and we can add wording to the specification to make it valid to skip the test for those as well.

I do not agree with changing the test to avoid the scenario entirely. It is valid usage of JCQL and ought to be tested for the database types that are capable of it.

@otaviojava
Copy link
Copy Markdown
Contributor Author

@njr-11 thanks for the clarification — I agree with you on the formal reading of the spec.

Yes, JCQL explicitly allows scalar_expression comparison_operator scalar_expression, and historically this grammar is clearly inspired by SQL and Jakarta Persistence. No disagreement there.

Even for Document and Graph databases, WHERE a = b is not uniformly supported or guaranteed to behave consistently. In practice, support varies significantly between providers, and index usage is often undefined or unavailable. From a user perspective, this makes the behavior effectively provider-dependent.

Given this reality for NoSQL providers, how does the specification intend to define the portability expectations for a = b comparisons?
Should this be treated as required only for relational providers and optional or skippable for non-relational ones?

@njr-11
Copy link
Copy Markdown
Member

njr-11 commented Jan 16, 2026

Given this reality for NoSQL providers, how does the specification intend to define the portability expectations for a = b comparisons?

I proposed a spec update for this under #1329 . Please review and let me know if you would like the wording adjusted.

@otaviojava
Copy link
Copy Markdown
Contributor Author

Thank you @njr-11

I am totally fine with this option as well.

Thus, I will close this PR.

@otaviojava otaviojava closed this Jan 16, 2026
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.

2 participants