openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elias Torres <el...@torrez.us>
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.

-Elias

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 u.id = ?
>>
>> as opposed to when I have the user id already.
>>
>> SELECT f FROM Foo f WHERE f.userid = ?
> SELECT f FROM Foo f WHERE f.user.id = ?
> 
>> 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
> 
> http://openjpa.apache.org/docs/latest/manual/manual.html#ref_guide_fetch
> 
> Note that this is not part of the JPA spec, but an OpenJPA extension.
> 
> Gokhan.
> 
> 

Mime
View raw message