AttachCallback javadoc issue

• Key: JDO-368
• Type: Bug
• Status: Resolved
• Resolution: Invalid
• Priority: Major
• Assignee: Craig Russell
• Reporter: Dave
• Component/s: api2
• Affects Version/s: JDO 2 rc1

Description

Javadoc issue.

Descriptions of the AttachCallback methods appear to be copied from DetachCallback. A copy is made during Detach, but not Attach. Which instance are these methods executed on? The attaching copy, or the persistent copy?



jdoPostAttach(java.lang.Object attached)
          This method is called during the execution of PersistenceManager.makePersistent(java.lang.Object) on the persistent instance after the copy is made.
 void jdoPreAttach()
          This method is called during the execution of PersistenceManager.makePersistent(java.lang.Object) on the detached instance before the copy is made.

Comments

[Craig Russell]

The AttachCallback methods are called during makePersistent if there is a detached instance among the reachable instances of the parameter to makePersistent.

During makePersistent on a detached instance, a persistent copy of the detached instance is made (or an existing persistent instance in the cache with the same object identity is located).

Thus, there are two distinct instances: the detached instance; and the corresponding persistent instance.

The jdoPreAttach method is invoked on the detached instance.

The jdoPostAttach method is invoked on the persistent instance, with the detached instance as the parameter.

   [[ Old comment, sent by email on Tue, 6 Jun 2006 09:38:41 -0600 ]]

Craig,

I think you missed the point of this bug report.
Your explanation below makes since and explains what is going on.

My point is that the JavaDoc documentation of these methods is confusing.

During attachment, the state of "the copy" that was previously detached is
synchronized with the original object and ultimately the with the
datastore.

Instead of "after/before the copy is made", it should say something like:
"after/before the detached object's state is transfered to the persistent
object's state".

upon whether the original persistent object instance is still in memory.



On 6/3/06, Craig Russell (JIRA) <[e-mail]> wrote: