openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar" <ppod...@bea.com>
Subject RE: [jira] Commented: (OPENJPA-396) Cloning Calendar proxies doesn't detach from StateManager
Date Mon, 08 Oct 2007 18:35:53 GMT
>I am proposing to modify 
>the generated proxy code to override the clone() method.  This 
>clone() method will do the necessary copying of data from the 
>original object, but then also null out the sm (StateManager) 
>and zero out the field attributes.  This action detaches the 
>cloned object from the StateManager (and associated EntityManager).

Who will invoke this Proxy.clone()? and when?

Are we now having 
A) the original user object x
B) the proxy of x
C) clone of proxy of x
D) copy of proxy of x, as generated by Proxy.copy() 

If the clone with no owning statemanager is the 'detached' SCO, then how
will the change in SCO be tracked in remote client?

Pinaki Poddar
972.834.2865
 

>-----Original Message-----
>From: Kevin Sutter (JIRA) [mailto:jira@apache.org] 
>Sent: Monday, October 08, 2007 12:54 PM
>To: dev@openjpa.apache.org
>Subject: [jira] Commented: (OPENJPA-396) Cloning Calendar 
>proxies doesn't detach from StateManager
>
>
>    [ 
>https://issues.apache.org/jira/browse/OPENJPA-396?page=com.atla
>ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
>_12533169 ] 
>
>Kevin Sutter commented on OPENJPA-396:
>--------------------------------------
>
>[ Show > ]
>Craig Russell - 08/Oct/07 10:25 AM Hi Kevin, One question. In 
>the generated clone method, after calling super.clone(), why 
>do you not simply invoke stateManager = null; pcState = 0; 
>instead of calling the setOwner(null, 0) method? Seems like 
>there is additional code in setOwner that you want to avoid 
>because there is not yet any relationship between the owner 
>and the sco. The effect of calling this method from the clone 
>might be to disassociate the original sco.
>
>Craig,
>The original reason is that I couldn't figure out the proper 
>serp invocations to just set those two fields.  :-)  Then, I 
>found the setOwner method on the Proxy (also generated code) 
>that did just what I was looking for.  So, it was more 
>straight-forward to just call this method than to repeat the same code.
>
>As far as I can tell, the setOwner has no other side effects.  
>I am calling setOwner on the Proxy, not the StateManager.  The 
>code is generated in the ProxyManagerImpl class 
>(addProxyMethods method).  And, the javadoc for this method is 
>as follows:
>
>    /**
>     * Reset the state of the proxy, and set the owning instance of the
>     * proxy and the name of the field it is assigned to. Set 
>to null to
>     * indicate that the proxy is no longer managed.
>     */
>    public void setOwner(OpenJPAStateManager sm, int field);
>
>Kevin
>
>
>> Cloning Calendar proxies doesn't detach from StateManager
>> ---------------------------------------------------------
>>
>>                 Key: OPENJPA-396
>>                 URL: 
>https://issues.apache.org/jira/browse/OPENJPA-396
>>             Project: OpenJPA
>>          Issue Type: Bug
>>          Components: kernel
>>    Affects Versions: 1.0.0, 1.0.1, 1.1.0
>>            Reporter: Kevin Sutter
>>            Assignee: Kevin Sutter
>>             Fix For: 1.0.1, 1.1.0
>>
>>         Attachments: OPENJPA-396.patch
>>
>>
>> This problem was first discussed on our dev mailing list:  
>> http://www.nabble.com/Cloning-Calendar-proxies-tf4571181.html
>> Per the discussion on that thread, I am proposing to modify 
>the generated proxy code to override the clone() method.  This 
>clone() method will do the necessary copying of data from the 
>original object, but then also null out the sm (StateManager) 
>and zero out the field attributes.  This action detaches the 
>cloned object from the StateManager (and associated EntityManager).
>> Instead of limiting this action to the Calendar proxy, I am 
>adding the clone() method implementation to all of our proxy 
>objects that we generate.  Granted, some of the object types 
>do not directly support the clone() method, but that will be 
>detected when or if anybody attempts to use the clone() method 
>on these types (compiler generated error message).
>> I'll be posting a patch shortly and I plan to commit the 
>changes later today (unless there is opposition).
>> Thanks,
>> Kevin
>
>--
>This message is automatically generated by JIRA.
>-
>You can reply to this email to add a comment to the issue online.
>
>

Notice:  This email message, together with any attachments, may contain information  of  BEA
Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,
 copyrighted  and/or legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient, and have received
this message in error, please immediately return this by email and then delete it.

Mime
View raw message