Hi Kevin, Sorry for the distraction.
My concern is really whether the proxy.setOwner is the tail or the dog.If it is the tail, then I have no problems with it. Some other actor is doing the work of synchronizing the state of the Entity, its StateManager, and the owned Proxy. So having the proxy simply take the value of setOwner and apply it is fine.
If the proxy.setOwner is ever the dog, that's where I have the issue. If it's the dog, then the implementation might call into the owning StateManager and ask it to make some state changes. And having the clone call the StateManager would be wrong, since what you're trying to do is make sure the clone stays unaware of the StateManager.
Craig On Oct 8, 2007, at 12:16 PM, Kevin Sutter wrote:
Craig, On 10/8/07, Craig Russell (JIRA) <[EMAIL PROTECTED]> wrote:[https://issues.apache.org/jira/browse/OPENJPA-396? page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#action_12533175]Craig Russell commented on OPENJPA-396: ---------------------------------------As far as I can tell, the setOwner has no other side effects.I hope someone else can comment on this, as it doesn't seem right. You don't want to <allow> any code in the clone to access the StateManager, since the StateManager knows about the original and can't tell from the APIswhich proxy is calling it.I think we're asking for trouble, either now or in future if we call thismethod from the clone.Can you clarify which setOwner you are nervous about? I am calling Proxy.setOwner(), not StateManagerImpl.setOwner(). The code forProxy.setOwner() is generated in ProxyManagerImpl.addProxyMethods (). Theonly thing that Proxy.setOwner() does is to set the sm and field attributes. In the clone() code that I am generating, I am calling Proxy.setOwner(null,0).Hope this helps clarify my usage. I'm still uncertain about your concerns.Thanks, KevinCloning Calendar proxies doesn't detach from StateManager--------------------------------------------------------- Key: OPENJPA-396URL: https://issues.apache.org/jira/browse/ OPENJPA-396Project: 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.htmlgenerated 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 associatedPer the discussion on that thread, I am proposing to modify theEntityManager).Instead of limiting this action to the Calendar proxy, I am adding theclone() method implementation to all of our proxy objects that wegenerate. Granted, some of the object types do not directly support the clone() method, but that will be detected when or if anybody attempts to usethe clone() method on these types (compiler generated error message).I'll be posting a patch shortly and I plan to commit the changes latertoday (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.
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
