Skip to content

[OPENJPA-2975] Narrow criteria TREAT joins instead of casting silently - #194

Merged
cristof merged 2 commits into
masterfrom
OPENJPA-2975
Sep 30, 2026
Merged

cristof merged 2 commits into
masterfrom
OPENJPA-2975

Conversation

@rzo1

@rzo1 rzo1 commented Sep 25, 2026

Copy link
Copy Markdown
Contributor

treat() on a join only cast the object, so no type narrowing was applied and queries silently returned supertype instances. The join now records the narrowed type, which makes attribute resolution work against the subclass and the kernel emit the same TREAT discriminator condition as JPQL (OPENJPA-2961); a treated root used only in the SELECT clause is now restricted too. Narrowing a correlated join and treat() on an arbitrary path are rejected with a clear UnsupportedOperationException instead of silently doing nothing, and TestTreatJoinCriteria covers both the narrowing and the diagnostics.

The treat(Join/CollectionJoin/SetJoin/ListJoin/MapJoin, Class) overloads
only cast their argument, so no type narrowing was applied at all. A
treated join now resolves its attributes against the narrowed type and
binds its kernel variable to the narrowed metadata, which renders the
same discriminator condition as a JPQL TREAT join, including the
subclasses of the treated class.

A join that is correlated to an outer query, or that is reached from
such a join, carries no kernel variable of its own, so there is no
variable that could carry the narrowed metadata. Such a join is now
rejected with an UnsupportedOperationException rather than being
narrowed without any effect.

treat(Path, Class) delegates to the Root and Join implementations and
rejects any other path expression with an UnsupportedOperationException
instead of returning it unnarrowed.

The type restriction of a treated root is evaluated after the projection
and ordering terms, so that it is applied for a root that is treated in
the select clause only, and it now matches the subclasses of the treated
class as well.
@rzo1 rzo1 self-assigned this Sep 25, 2026
@rzo1
rzo1 requested review from cristof and solomax September 25, 2026 20:06

@cristof cristof left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'd rather use some enhanced loops in the test, but it seems good enough.

TLineItem.class, TOrder.class, DROP_TABLES);

try (EntityManager em = emf.createEntityManager()) {
em.getTransaction().begin();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

shall the rollback be called in case of error? (with nested try?)
Of it should be handled automatically?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

If it fails, all tests fails. Repeating the test will call DROP_TABLES. I've fixed the varargs warnings and thus gonna merge it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

how hard would be to eliminate these warnings?

@cristof
cristof merged commit cf36da3 into master Sep 30, 2026
4 checks passed
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.

3 participants