Take the 2-minute tour ×

I have a query with a self join that looks like this,

select t1., t2. from table t1 left outer join table t2 on t2.LFT < t1.LFT and t2.RGT > t1.RGT AND t2.REG_CODE_PAR = 'ALL' AND t1.STATUS_CODE = 'A' AND t2.STATUS_CODE = 'A'

I'm using @NamedNativeQuery with a result set mapping to get the result.

    query="..... the query above", 
    resultSetMapping = "regionT")

With the following result set mapping

@SqlResultSetMapping(name = "regionT" , entities ={
        entityClass = Tree.class
        fields = {
            @FieldResult(name = "regCode", column = "REG_CODE")
            @FieldResult(name = "rgt", column = "RGT"),
            @FieldResult(name = "lft", column = "LFT"),
            @FieldResult(name = "name", column = "NAME"),
            @FieldResult(name = "regCodePar", column = "REG_CODE_PAR"),
            @FieldResult(name = "statusCode", column = "STATUS_CODE")
        entityClass = TreeSelf.class
        fields = {
            @FieldResult(name = "regCode1", column = "REG_CODE")
            @FieldResult(name = "rgt1", column = "RGT"),
            @FieldResult(name = "lft1", column = "LFT"),
            @FieldResult(name = "name1", column = "NAME"),
            @FieldResult(name = "regCodePar1", column = "REG_CODE_PAR"),
            @FieldResult(name = "statusCode1", column = "STATUS_CODE")

The entity class contains looks like this.

@Table(name = "table")
public class Tree implements Serializable {

    @Column(name = "REG_CODE")
    private String regCode;  ... ..getters and setters...}

When I run the query using em.createQuery("findTree"), I get the exact same object in both

the 1st and 2nd elements of the returned object array. Even if I create a class called TreeSelf that is identical to Tree and use it as the 2nd

EntityResult instead of having 2 EntityResults using the same entityClass, I get the same


Can someone point out what's wrong with the configuration?

share|improve this question
Did you mean to print select t1.*, t2.* instead of select t1., t2.? Looks like the formatter tripped you up. –  Dan LaRocque Jul 23 '10 at 6:03
add comment

1 Answer

up vote 1 down vote accepted

Let's see if I understand your question. You're expecting to capture two Tree entities from each native query result row. The first entity should be formed from t1's columns. The second entity should be formed from t2's columns. Contrary to expectation, you actually receive two instances formed from t1. No instances from t2 appear. You made a doppelganger Entity for Tree called TreeSelf while debugging, but TreeSelf is ultimately unnecessary and you want to get rid of it. Stop me if any of that was wrong.

I think the problem is due to ambiguous column names. Each column name in the native query appears twice, once from t1 and once from t2. The result mapper seems to be arbitrarily picking the first occurrence of each ambiguous column name for both Tree entities. I'm surprised that works at all. I would have expected an SQLException complaining about column reference ambiguity.

Also, are you sure you want a left outer join? What if no match is found for a t1 row? It will be paired with all NULL in t2's columns. Then you have a null-valued Tree entity. I think. I don't even know what the result mapper would do in that case. Perhaps you want an inner join?

Consider translating this native query into a JPQL query. (JPA Criteria API is just as well, but I find it more cumbersome for examples.) Here's a JPQL version of the native query:

SELECT t1, t2 
FROM Tree t1, Tree t2
WHERE t2.lft < t1.lft AND t2.rgt > t1.rgt AND t2.regCodePar = 'ALL' AND
      t1.statusCode = 'A' AND t2.statusCode = 'A'

N.B.: This changes the join semantics to inner instead of left outer.

Here's a sketch of code that could run this query:

EntityManager em = ... // EntityManager by injection, EntityManagerFactory, etc.
String jpql      = ... // Like example above
TypedQuery<Object[]> q = em.createQuery(jpql, Object[].class);

for (Object[] oa : q.getResultList()) {
   Tree t1 = (Tree)oa[0];
   Tree t2 = (Tree)oa[1];

In case you are stuck with the native query for whatever reason, here's how you can work around the column name ambiguity. Instead of starting the native query like select t1.*, t2.*, alias each column with AS. The SELECT clause would resemble this:

SELECT t1.REG_CODE AS t1_REG_CODE, t1.RGT AS t1_RGT, (... rest of t1 cols ...), 
       t2.REG_CODE AS t2_REG_CODE, t2.RGT AS t2_RGT, (... rest of t2 cols ...)

The column attribute in each FieldResult must change accordingly. So the column attributes under the first EntityResult should all start with t1_ and the second's should all start with t2_.

I'd humbly recommend deleting the native query and sql result mapper and using JPA Query Language or Criteria API, if you can find a way.

Update: As confirmed in your comments, a useful answer to your question must preserve left (outer) join semantics. Unfortunately, JPQL and the Criteria API don't support complex left join conditions. There is no way to qualify a JPQL left join with an explicit ON condition.

To my knowledege, the only way to do a left outer join under the spec is by traversing an entity relationship. The JPA implementation then generates an ON condition that tests identity equality. The relevant spec bits are 4.4.5 "Joins" and "Left Outer Joins".

To satisfy this constraint, each Tree you want to left-join to its ultimate parent must have an additional column storing the ultimate parent's id. You might be able to cheat around this constraint in a variety of ways (views?). But the path of least resistance seems to be modifying the native query to use aliased arguments, deleting TreeSelf, and updating the result mapper accordingly. Cleverer solutions welcome, though...

share|improve this answer
Hi Dan, thanks for your insight. Yes you understood my question correctly but let me give you some history. This is an existing query in the system. My aim is to convert it to JPA Criteria API but ran into problems because of the multiple conditions on the left join (Yes the left join is required. The null case is handled in the application). I posted this question here: stackoverflow.com/questions/3280381/… –  Jonathan Jul 26 '10 at 4:46
Another problem with JPQL I faced is that the Tree data structure is a hierarchy in the table. Each row has a column (parent_id) which refers to the PK of another row in the table. By doing a @ManyToOne @JoinColumn(name = "parent_id") private Tree tree; I'd obtain its immediate parent. The result from t2 in the native query actually returns the top level parent record and not the immediate parent. Using JPQL, I'd have to Tree.getTree().getTree().getTree().....getTree() up to 6 or 7 levels to get the top level parent. –  Jonathan Jul 26 '10 at 5:02
All these being said, my preference is to use JPA Criteria if the multi-condition join and the top parent problems can be solved. If you have an opinion, I'd very much like to hear it. Thanks –  Jonathan Jul 26 '10 at 5:07
@Jonathan - thanks for clarifying and linking to the related question. To the best of my knowledge, there's no easy way to do this left join in JPQL or Criteria API without modifying the entities and or backing database objects in some way. I added an update at the end of the answer with details. –  Dan LaRocque Jul 27 '10 at 17:38
thanks for your reply. Very much appreciated. I had already read the specs. Just wondering if anyone has an elegant solution to this –  Jonathan Aug 4 '10 at 3:19
add comment

Your Answer


