JPA - 在 EclipseLink 中忽略 namedQuery 中的连接操作

JPA - Ignore join operation in namedQuery in EclipseLink

我有以下情况

  1. 实体表A:

         @Entity
         @Table(name = "TABLE_A")
         @NamedQueries({
                 @NamedQuery(name = "TableA.namedQ1", query = "SELECT t1 FROM TableA t1 JOIN FETCH t2.TableB t2"
                         + " WHERE <conditions here>"),
                 @NamedQuery(<Need query here which will ignore mapping below and return rows only for TableA>)
                 }   )
         public class TableA implements Serializable{
    
         @Id
         @Column(name = "id")
         private int id
    
         ...
         ...
         ...
    
         @OneToMany(mappedBy = "tableA", cascade = CascadeType.ALL ,fetch=FetchType.LAZY)
         private List<TableB> tableB;
    
    
    
    
         }
    
  2. 实体表 B :

         @Entity
         @Table(name = "TABLE_B")
         public class TableB implements Serializable{
    
         @Id
         @Column(name = "id1")
         private int id1
    
         ...
         ...
         ...
    
    
    
    
         @ManyToOne
         @JoinColumn(name = "id",insertable = false, updatable = false)
         private TableA tableA;
    
    
    
         }
    

我面临以下两个问题:

  1. 上面提到的查询即

          SELECT t1 FROM TableA t1 JOIN FETCH t2.TableB t2
    

需要很长时间才能执行。大约 30 秒。但是对相同数据集的相同查询在 SQL 开发人员中几乎不需要 3-4 秒。我应该在代码中做些什么来让它 运行 更快?

  1. 我有不需要其他 table 数据的要求(通过映射检索)。我只需要来自 TableA 的数据。我尝试了下面的命名查询,但它 运行 针对 TableA 中的每一行对 TableB 进行单独查询,这需要 4 分钟以上的时间来执行。

       "SELECT t1 FROM TableA t1 where <condition goes here>"
    

    我必须在查询中进行哪些修改才能忽略映射。我需要保留注释(@OneToMany),因为我将在 namedQ1 中需要它。

感谢期待

当您使用 FETCH 时,您要求检索集合中的数据 进步。如果您不需要 TableB 中的元素,那么您的查询应该是:

SELECT t1 FROM TableA t1 left join t1.tableB t2

请注意,仅当您需要向 t2 添加一些条件时才需要连接。 例如:

SELECT t1 FROM TableA t1 left join t1.tableB t2 WHERE t2.field = 123

如果这不是你的情况,那么这应该足够了:

SELECT t1 FROM TableA t1;

在所有这些情况下,它都会为集合创建一个代理 TableB 并且不需要访问数据库中的 table,除非您稍后需要使用该集合。

对于任何有类似问题的人

  Question 1 in OP : 

  Question 2 in OP: Solved using @Davide solution