Hi Markus,
The JPA spec in the section 9.1.9 GeneratedValue Annotation says about various
strategies: "This specification does not define the exact behavior of these
strategies.". It might be a known bug in TopLink, but we always advised to call
em.flush() if somebody needed to get a hold of the generated PK.
Regards,
-marina
Markus KARG wrote:
> Hi all,
>
> as you know, I am the author of the Sybase support in TopLink
> Essentials. :-)
>
> I just tried a short code snipped and noticed a strange behaviour. Since
> I do not know whether that is wanted by JPA spec, or a bug of TopLink,
> or a bug of my own code, I want to discuss with you prior to filing a
> bug report.
>
> See the following code snippet:
>
> em.getTransaction().begin();
> Article a1 = new Article();
> em.persist(a1);
> System.out.println(a1.getId()); // Prints: 0
> Article a2 = em.find(Article.class, 60);
> System.out.println(a2.getId()); // Prints: 60
> em.getTransaction().commit();
>
> "Article" is an entity that is using IDENTITY strategy for generating
> its primary key:
>
> @Id
> @GeneratedValue(strategy = GenerationType.IDENTITY)
> private int id;
>
> The database wrapper used, obviously, is the one I wrote. ;-)
>
> As you can see, when asking for the generated ID directly after
> em.persist(a1), it returns the wrong value of 0. In fact, it certainly
> shall tell the actually generated value of 60, since it is impossible to
> know that value -- and such it is impossible to ask for that PK
> explicitely as I have done it in the em.find() line. But knowing the PK
> might be critical to some use cases. In fact, my Sybase wrapper included
> in TopLink so far has code that reads back the created value -- but it
> seems that value gets lost "somewhere". I know that somebody changed my
> code recently to support IDENTITY and SEQUENCE strategy at the same
> time. Maybe he broke it?
>
> So my question is: IS THAT A BUG?
>
> And if it is: Is that a bug of my Sybase wrapper, or a bug of TopLink?
>
> Thanks
> Markus
>