Hello All,
"fetch groups" or "operation groups" do have their usefulness for pre-serialization processing and merging. Whatever structures are created it would be valuable to define them a generic way allowing them to be applied to other operations other than just attribute loading.
--Gordon
On 12/5/2011 5:32 AM, Rainer Kwesi Schweigkoffer wrote:
> Hi Linda, all,
>
> me, I think we should have a look into the fetch groups/profile
> stuff. From my point of view it's awfully needed to establish a
> contract on what has been loaded.
>
> Best regards
> Rainer
>
> Am 2 Dec 2011 um 13:33 hat Linda DeMichiel geschrieben:
>
>> Thanks, Scott.
>>
>> Changing the subject and snipping out the previous discussion here so that the
>> Scott's suggestion doesn't get buried in the thread....
>>
>>
>> On 12/1/2011 8:37 PM, Scott Marlow wrote:
>>
>>> I was thinking more about the lazy associations problem. Is there room in the JPA 2.1 specification, to make an
>>> enhancement that improves what applications experience when the entity manager is invoked outside the scope of a
>>> transaction? I'm thinking that the container could have a way to give a hint to the persistence provider, that lazy
>>> fetching should not be used for the entity manager invocation. The advantage of this enhancement, is that applications
>>> will successfully be able to access the loaded entity(s) that currently fail (due to lazy fetching being used). I think
>>> that the application can also make changes to work around this (e.g. use FetchType.EAGER) but I would like the same
>>> (FetchType.LAZY) entity/association to work with both container/app managed entity managers (that don't run in a JTA
>>> transaction).
>>>
>>> Perhaps this could be a (new) standard property that the container could pass to
>>> EntityManagerFactory.createEntityManager(Map) that suggests that lazy fetching should be disabled. Or something more
>>> generic that covers other possible problems. e.g. some hint like "javax.persistence.auto-detach" that lets the provider
>>> know that loaded entities will be detached (so the provider can avoid using lazy fetching).
>>>
>> Folks, I'd like to get more opinions on this. Should we pursue this direction?
>> Should we try to address this issue via fetch groups/profiles? Other?
>>
>> thanks,
>>
>> Linda
>>
> ---
> Rainer Schweigkoffer SAP AG Walldorf
> Business Solution& Technology TD Core JI
> Technology Development Dietmar-Hopp-Allee 16
> Java Server Core D-69190 Walldorf
> JEE Implementation Group phone: +49 6227 7 45305
> Building 3, I.3.14 fax: +49 6227 7 821177
> rainer.schweigkoffer_at_sap.com
>
> Sitz der Gesellschaft/Registered Office: Walldorf, Germany
> Vorstand/SAP Executive Board: Werner Brandt, Bill McDermott (Co-CEO),
>
> Gerhard Oswald, Vishal Sikka, Jim Hagemann Snabe (Co-CEO)
> Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
> Board: Hasso Plattner
> Registergericht/Commercial Register Mannheim No HRB 350269
>
> Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse oder sonstige
> vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
> irrtuemlich erhalten haben, ist Ihnen eine Verwertung des Inhalts,
> eine Vervielfaeltigung oder Weitergabe der E-Mail ausdruecklich
> untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
> empfangene E-Mail. Vielen Dank.
>
> This e-mail may contain trade secrets or privileged, undisclosed, or
> otherwise confidential information. If you have received this e-mail
> in
> error, you are hereby notified that any review, copying, or
> distribution
> of it is strictly prohibited. Please inform us immediately and
> destroy the
> original transmittal. Thank you for your cooperation.
>
>
>