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?
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 ____________________________________________________________ This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to which they are addressed. Any unauthorized copying, disclosure, or distribution of the material within this email is strictly forbidden. Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Odyssey Financial Technologies SA unless otherwise specifically stated. An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. If you have received this email in error, please notify the sender immediately and delete the original.
