You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by it...@daimler.com on 2009/05/20 11:10:37 UTC

@Version annotated Field not included in SELECT (prepstmnt)

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.  

Re: @Version annotated Field not included in SELECT (prepstmnt)

Posted by Craig L Russell <Cr...@Sun.COM>.
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!