openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elias Torres <>
Subject Re: How to map multiple properties to same column as writable in jpa
Date Fri, 27 Jul 2007 15:14:30 GMT
Thanks Gokhan.

I definitely should read the OpenJPA like a novel instead of only going
through when I need help.

I'll be trying insertable=false and updatable=false first. That's
exactly what I think I need. Later, I'll try @Transient and the family
of events, but like you said, it's much riskier.

I had already read about fetchgroups but have not tried it.


Gokhan Ergul wrote:
> Elias Torres wrote:
>> @ManyToOne(fetch=FetchType.LAZY)
>> @JoinColumn(name="userid", referencedColumnName="id")
>> private User user;
>> and
>> @Column(name="userid")
>> private String userId;
> @Column(name="userid", insertable=false, updatable=false)
> private String userId;
>> How would I go about keeping them in sync? Especially, when someone
>> calls setUser(user) with a new instance that might not have an id.
> AFAIK there's no built-in mechanism to keep those two members in sync.
> One possibility is to write the sync code in setX() methods (pre-flush
> sync) and provide a PostPersist method to sync after commit. A similar
> approach would be making "userId" non-managed (i.e. @Transient), and
> using a combination of PostLoad/PostPersist/setX to keep the two members
> in sync.
> Though I should warn that things get pretty hairy if you have a
> highly-connected object model and manipulating entities in a detached
> context (as in moving entities to a different tier, "editing" them and
> moving them back to server tier, over rmi, webservices or whatnot).
>> SELECT f FROM Foo f JOIN f.user u WHERE = ?
>> as opposed to when I have the user id already.
>> SELECT f FROM Foo f WHERE f.userid = ?
>> Is it a practice to create multiple versions of an entity (light vs
>> heavy) to optimize the queries? One with @ManyToOne and another with
>> @Basic.
> That really depends on your application requirements, but for most
> distributed applications you'll have to come up with a way to retrieve
> "shallow" vs. "deep" objects --for standalone apps that's much less of a
> concern. In case you need to do it, see
> Note that this is not part of the JPA spec, but an OpenJPA extension.
> Gokhan.

View raw message