Alexis,
> Hi Markus,
>
> Thanks for documenting this all.
> Do you want to add this yourself to the FAQ on the Wiki?
> http://wiki.glassfish.java.net/Wiki.jsp?page=GlassFishUserFAQ
>
> thanks,
> -Alexis
Okay, I am willing to contribute that to the FAQ. But I think that the
best place is not the GlassFishUserFAQ but the Persistence FAQ:
https://glassfish.dev.java.net/javaee5/persistence/persistence_faq.html
Unfortunately I did not find out where to click to add something to that
FAQ. Has anybody an idea how to gain write access to the Persistence FAQ?
Thanks
Markus
>
> On Jan 4, 2008, at 9:44, Markus KARG wrote:
>
>> Marina,
>>
>> thank you for your kind answer.
>>> 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.
>> You are absolutely right, I was just blind that day. ;-)
>>
>> In particular, I found the following in JPA 1.0 specification chapter
>> "3.2.1 Persisting an Entity Instance":
>>
>> "A new entity instance becomes both managed and persistent by
>> invoking the persist method on it or by cascading the persist
>> operation. The semantics of the persist operation, applied to an
>> entity X are as follows: • If X is a new entity, it becomes managed.
>> The entity X will be entered into the database at or before
>> transaction commit or as a result of the flush operation."
>>
>> Okay, that says it all: A user MUST invoke flush() or commit() to
>> make the O/R mapper talk to the database server, so it is NOT a bug,
>> neither of TopLink in general, nor of the particular part of TopLink
>> that I wrote. That completely and unambigously answers my question.
>> Once more it was helpful to ask before filing a bug report. :-)
>>
>> For all people scanning the mailing list for a solution to the same
>> problem, here is the corrected code that works pretty well:
>>
>> em.getTransaction().begin();
>> Article a1 = new Article();
>> em.persist(a1);
>> em.flush(); // <--- FLUSH (OR COMMIT) IS NEEDED HERE
>> System.out.println(a1.getId()); // Prints: 60 // Prints: 0 WITHOUT
>> flush() or commit()
>> Article a2 = em.find(Article.class, 60);
>> System.out.println(a2.getId()); // Prints: 60
>> em.getTransaction().commit();
>>
>> Maybe someone likes to add this snippet tho the user's FAQ. :-)
>>
>> Thanks for pointing me in the right direction!
>>
>> Have Fun
>> Markus
>>>
>>> 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
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> --
>> http://www.xing.com/go/invita/58469
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
--
http://www.xing.com/go/invita/58469