Hi Pinaki, 

Thanks for your answer, it is a way to solve our issue. I've still a 
question: will the OpenJPAStateManager access still work properly on 
detached object in every case? 


Pinaki Poddar wrote:
> 
> The short answer is you need to get hold of OpenJPAStateManager for A --
> the proxy object that intercepts and manages the persistent state of
> original A. That StateManager has the primary key of B which saves OpenJPA
> another join in case the user later calls A.getB().
> 

However, your proposal has the inconvenient of using OpenJPA internals 
(which are more subject to change than standard JPA api). In the 
meanwhile I was wandering if a solution like mapping the column twice 
could work: 

@ManyToOne(cascade = CascadeType.PERSIST, fetch = FetchType.LAZY) 
@Column(name = "dsit_one_bref_id") 
private dsimpltest.BRealClassEntity oneBRef; 

@Column(name = "dsit_one_bref_id", insertable=false, updatable=false) 
private String oneBRefKeyAtt; 

Obviously, this will work in reading data. Maintaining the second 
attribute in synch with the first attribute will need 
@PostUpdate/@PostPersist interceptors and some logic in the setter of 
oneBRef. 

Anyway, can you tell me if it is a bad idea? 


Hi Craig, 

In our case we instruct the fetch plan not to get the FB objects as we 
only need to know its primary key. Doing this save us from a JOIN during 
the query. Unfortunately, when accessing the data, the objects are 
detached and getting FB leads us to a FB null. So from here it is not 
possible to get the id (but we can get it using the Pinaki's solution) 

Yann 
-- 
View this message in context: 
http://n2.nabble.com/Get-%40Id-field-value-%28FK%29-without-loading-entity-%28JOIN%29-when-using-FetchGroups-or-Lazy-Loading-tp1499463p1581096.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Reply via email to