How do you join two entities in a JPQL or HQL query when there is no mapped association between them?

## The problem JPQL joins normally traverse a mapped association. If `Account` and `Ledger` share a business key but no `@ManyToOne` connects them — perhaps deliberately, because they belong to different modules — there is no path to write. Historically this pushed people to native SQL. ## Entity joins (ad-hoc joins) Hibernate 5.1 introduced joining an entity name directly with an arbitrary ON condition, and Jakarta Persistence 3.2 brought the same capability into the specification: ``` select a.id, l.balance from Account a join Ledger l on l.accountCode = a.code where a.status = :status ``` Properties of this form: - The right side is an **entity name**, not an association path. - The ON clause is mandatory in practice — without it you get an unrestricted join. - `LEFT JOIN` works, so you can keep accounts that have no ledger row. This is the capability the old cross-join trick lacks. - The joined alias is a full entity alias: you can select it, filter on it, navigate its own associations from it. ## The legacy alternative: implicit cross join ``` select a, l from Account a, Ledger l where l.accountCode = a.code ``` Listing multiple roots in FROM is a Cartesian product; the WHERE predicate reduces it, and every database planner recognises the shape and executes it as an inner join. This works on any JPA version. Two caveats: it can only express inner-join semantics, and if the predicate is dropped in a refactor you silently get an N×M explosion, which on production-sized tables is a serious incident rather than a slow query. ## When ad-hoc joins are the right answer - **Reporting and analytics queries** that combine entities the domain model has no reason to link. - **Deliberate module decoupling**: two aggregates reference each other only by identifier, so no association exists by design, yet one screen needs both. - **Joining on a business key** rather than a surrogate foreign key — for example matching by an external system's code. - **Temporal or versioned lookups**, where the "association" depends on a date range and cannot be a single foreign key. ## When to map instead If the two entities really do have a stable one-to-many or many-to-one relationship and you find yourself writing the same ON condition everywhere, the mapping is missing. A mapped association gives you type-safe navigation, cascading, fetch control and entity-graph participation; an ad-hoc join gives you none of that. Repeating a join condition across many queries is a design smell, not a JPQL technique. ## Related capability: derived roots and subquery joins Hibernate also allows joining a *subquery* (a derived root) with an ON condition in HQL, which is how you express lateral-style lookups such as "the latest ledger row per account". Jakarta Persistence 3.2 likewise adds subqueries in the FROM clause. This is more advanced and less portable, but it is the natural next step once ad-hoc joins are on the table. ## Practical notes - Nothing about an entity join changes the persistence context: joined entities you select are managed as usual, and joined entities you merely filter on are not loaded. - Because there is no mapping, nothing validates your condition. A typo in the ON clause produces a silently wrong result set instead of a compile-time or bootstrap error — which is a real argument for keeping these queries covered by tests. - Column types must be compatible; joining a string code to a numeric id will either fail or perform terribly due to implicit conversion.