我們試圖在我們從其他人的應用程序導入的某些只讀表上創建JPA映射。這些是多個100億行表,因此更改模式不是一種選擇。我們有一個表,具有OBJECT_ID值的Message表和具有另一個表的DistributionGroup表,它們將具有許多與任何給定的OBJECT_ID關聯的ENTITY_ID行。有關表定義如下:JPA Unidrectional OneToMany通過JoinColumn返回相同的記錄n次而不是n次不同的記錄
CREATE TABLE Message (
OBJ_ID varchar(255) NOT NULL,
FileName varchar(255) NOT NULL,
KEY FileName (FileName)) ENGINE=InnoDB;
CREATE TABLE DistributionGroup (
OBJ_ID varchar(255) NOT NULL,
ENTITY_ID varchar(255) NOT NULL,
KEY OBJ_ID (OBJ_ID)) ENGINE=InnoDB;
而且JPA映射鏈接這兩個:
public class MessageRecord {
private String obj_id;
private String file;
private List<DGRecord> list = new ArrayList<DGRecord>();
@Id
@Column(name = "OBJ_ID", nullable = false)
public String getObjID() { return obj_id; }
public void setObjID (String obj_id) { this.obj_id = obj_id; }
//... (Similar for FileName)
@OneToMany
@JoinColumn(name="OBJ_ID", referencedColumnName="OBJ_ID")
public List<DGRecord> getDGRecordList() { return list; }
public void setDGRecordList(List<DGRecord> list) { this.list = list; }
}
public class DGRecord {
private String obj_id;
private String entity_id;
@Id
@Column(name = "OBJ_ID", nullable = false)
public String getObjID() { return obj_id; }
public void setObjID (String obj_id) { this.obj_id = obj_id; }
@Column(name = "ENTITY_ID", nullable = false)
public String getEntityId() { return entity_id; }
public void setEntityId (String entity_id) { this.entity_id = entity_id; }
}
現在,當我們運行一些代碼來遍歷所有的怪位發生對於給定的MessageRecord DGRecords:
MessageRecord record = [obtained earlier];
for (DGRecord dg : record.getDGRecordList()) {
System.out.println(dg.getEntityId());
//Do some work with the ENTITY_ID
}
當我對數據庫手動運行該操作中,我得到了我期待看到:
SELECT * FROM DistributionGroup WHERE OBJ_ID = 'ArbitraryObjID';
OBJ_ID, ENTITY_ID
ArbitraryObjID, EntityID1
ArbitraryObjID, EntityID2
ArbitraryObjID, EntityID3
但是從實際的代碼的輸出,當record
具有相同ArbitraryObjID
是:
EntityID1
EntityID1
EntityID1
對於任何給定的組合,它沒有返回n個不同DGRecords,但同樣DGRecord值n次,其中n是手動運行查詢返回的不同行的數量。我不確定這是否相關,但它實際上循環了同一個對象n次(由System.out.println(dg)證明返回相同的[email protected] n次)。
我們做錯了什麼,我們該如何解決?請記住,表格模式更改或添加連接表格的成本太高,以至於無法實現。但是,鑑於目前的設置,它似乎仍然能夠工作,因爲它與人類一樣足夠好。
'[較早獲得]',是使用一些查詢? – 2012-04-22 20:31:35
是的。內置了很多邏輯,但理想情況下,我們查詢FileName上的Message表並獲得一個結果。或者做一堆工作,讓我們最終得到一個有效的MessageRecord。我驗證了MessageRecord.getObjID在我描述的情況下與ArbitraryObjID匹配。 – 2012-04-22 20:44:33