openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: @Version annotated Field not included in SELECT (prepstmnt)
Date Wed, 20 May 2009 17:06:35 GMT
Hi Heiko,

<jpa spec p. 383>
The following types are supported for version properties: int,  
Integer, short, Short, long,
Long, Timestamp.
</jpa spec>

Try changing the type of the version field and see if that helps.

If so, please file a JIRA to give an error message instead of a silent  
fail.

Thanks,

Craig

On May 20, 2009, at 2:10 AM, it-media.kopp@daimler.com wrote:

> Hello,
>
> I'm having an issue in openJPA 1.2.1 with a entity model as follows:
>
> @Entity
> @Table(name = "PARTNER", schema = "PART")
> @NamedQuery(name = "getPartner", query = "SELECT p FROM Partner p  
> where
> p.partKey = :partKey")
> public class Partner
> {
>    @Id
>    @Column(name = "PART_KEY")
>    private BigDecimal partKey;
>
>    @OneToMany(mappedBy = "partner", fetch = FetchType.LAZY)
>    private List<PartnerRolle> rollen;
> }
>
> @Entity
> @Table(name = "PARTNERROLLE")
> public class PartnerRolle
> {
>    @EmbeddedId
>    private PartnerRolleKey key;
>
>         @Version
>    @Column(name = "VERSION")
>    private BigDecimal version;
>
>    @ManyToOne(fetch = FetchType.LAZY)
>    @JoinColumn(name = "PART_KEY")
>    private Partner partner;
> }
>
> When I ask for a Partner and later on call getRollen(), in the
> corresponding SELECT (prepstmt), the Column VERSION of PARTNERROLLE  
> is NOT
> queried (not listed in the SELECT). When I remove the @Version  
> annotation,
> it works corerctly, thus the VERSION is filled with the correct  
> value. It
> only works as expected, when I do NOT set @Version to that column.
>
> I doubt this is correct behaviour, cause even though its a simple  
> query,
> ALL annotated columns should be returned, whether or not they  
> changed. I
> was relying on the return of the VERSION field and ran into a
> NullPointerException because the BigDecimal was not correctly  
> instatiated.
>
> Any suggestion, even if it is "this is correct behaviour, because ..."
> would be appreciated.
>
> Thanx,
>
> Best regards,
>
> Heiko
>
> If you are not the intended addressee, please inform us immediately  
> that you have received this e-mail in error, and delete it. We thank  
> you for your cooperation.

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message