Undefined portability of NOT NULL semantics across SQL and NoSQL [TCK]

[otaviojava]

Jakarta Data aims to support both SQL and NoSQL datastores, but NOT NULL semantics are not portable across these models.

In SQL:

• Schema-defined columns always exist
• Missing values are represented as NULL
• IS NOT NULL has well-defined behavior

In NoSQL (especially Document/Graph):

• Attributes may be absent or explicitly set to null
• These are distinct states
• Query engines often distinguish between exists, absent, and not null

Because of this, tests such as:

• RestrictionTests.testNotNullRestrictionAllFound
• RestrictionTests.testNotNullRestrictionSomeFound

implicitly assume SQL semantics that cannot be guaranteed across NoSQL providers.

Question:

How should the TCK define portability expectations for NOT NULL?

• Relational-only guarantee?
• Provider-defined semantics for NoSQL?
• Explicit distinction between EXISTS and IS NOT NULL (even EXISTS making sense only to NoSQL?)

[gavinking]

If the idea is to add a new operator, then this would be an issue for the Query spec, no?

[otaviojava]

If the idea is to add a new operator, then this would be an issue for the Query spec, no?

The scope here is the TCK, but I will raise this point on Jakarta Query as well.

Thanks @gavinking

[otaviojava]

Raised

jakartaee/query#108