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.
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
>>
>
>