Marina Vatkina schrieb:
> Hi Markus,
>
> It's checked in under <src>/www/javaee5/persistence, but with the v3
> work, I'm not sure how it'll work in the long run.
>
> There is also a wiki version with a pointer to this (old) page where
> you can add your notes. Will it work for you?
>
> May be somebody would volunteer to convert the Persistence FAQ into a
> wiki format? We can then replace the original page with the link to
> the new wiki.
I will just wait until somebody converted the Persistence FAQ into wiki
format, to not make the same work several times... ;-)
Thanks
Markus
>
> thanks,
> -marina
>
> Markus KARG wrote:
>> 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
>>>
>>
>>
>
> ---------------------------------------------------------------------
> 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