You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig Russell <Cr...@Sun.COM> on 2005/09/21 00:01:55 UTC

Detach test case names

Hi Matthew,

Here are some test case names for review. This is from the  
spreadsheet. See how well it comes out in email.

Craig

A12.6.8-1
We define a new property called DetachOnClose  
PersistenceManager.setDetachOnClose(boolean detachOnClose) sets the  
DetachOnClose property


no
api/persistencemanager/detach/GetSetDetachOnClose
A12.6.8-2
PersistenceManager.getDetachOnClose() gets the value for the  
DetachOnClose property


no
api/persistencemanager/detach/GetSetDetachOnClose
A12.6.8-3
With this flag set to true, after close, the PersistenceManager  
guarantees that all persistent instances in the cache behave as  
detached instances


no
api/persistencemanager/detach/DetachOnCloseCreatesDetachedInstances
A12.6.8-4
can be serialized as detached instances.


no
api/persistencemanager/detach/SerializeCreatesDetachedInstances
A12.6.8-5
restored serialized instances are treated as detached instances.


no
api/persistencemanager/detach/RestoreSerializedInstances
A12.6.8-9
The order of instances in the parameter Collection’s iteration  
corresponds to the order of corresponding instances in the returned  
Collection’s iteration.


no
api/persistencemanager/detach/DetachOrderOfDetachedInstances
A12.6.8-10
If a detachCopy method is called with an active transaction, the  
parameter Collection of instances is first made persistent, and the  
reachability algorithm is run on the instances


no
api/persistencemanager/detach/DetachReachabilityOfDetachedInstances
A12.6.8-11
If a detachCopy method is called outside an active transaction, the  
reachability algorithm will not be run; if any transient instances  
are reachable via persistent fields, a JDOUserException is thrown for  
each persistent instance containing such fields.


no
api/persistencemanager/detach/ 
DetachTransientInstancesOutsideTransactionThrowsException
A12.6.8-12
If a detachCopy method is called outside an active transaction, the  
NontransactionalRead property must be true or JDOUserException is  
thrown.


no
api/persistencemanager/detach/ 
DetachOutsideTransactionRequiresNontransactionalRead
A12.6.8-13
For each instance in the parameter Collection, a corresponding  
detached copy is created.


no
api/persistencemanager/detach/DetachCreatesCopies
A12.6.8-14
If there are duplicates in the parameter Collection, the  
corresponding detached copy is used for each such duplicate.


no
api/persistencemanager/detach/DetachDuplicatesCreatesSingleInstance
A12.6.8-15
Instances in the persistent-new and persistent-dirty state are  
updated with their object identity and version


no
api/persistencemanager/detach/DetachNewAndDirtyInstancesAreUpdated
A12.6.8-16
If instances in a deleted state (either persistent-deleted or  
persistent-new-deleted) are attempted to be detached, a  
JDOUserException is thrown with nested JDOUserExceptions, one for  
each such instance.


no
api/persistencemanager/detach/DetachDeletedInstancesThrowsException
A12.6.8-17
All fields outside the FetchPlan in the detached instances are set to  
the Java language default value for the type of the field.


no
api/persistencemanager/detach/DetachedUnloadedFieldsHaveDefaultValues
A12.6.8-18
Fields in the FetchPlan of primitive and wrapper types are set to  
their values from the datastore


no
api/persistencemanager/detach/DetachFieldsLoadedFromDatabase
A12.6.8-19
Fields of references to persistence-capable types are set to the  
detached copy corresponding to the persistent instance.


no
api/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances
A12.6.8-20
Fields of Collections and Maps are set to detached SCO instances  
containing references to detached copies corresponding to persistent  
instances in the datastore.


no
api/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances
A12.6.8-21
While detached, any field access to a field that was not fetched  
throws JDODetachedFieldAccessException.


no
api/persistencemanager/detach/AccessingUnloadedFIeldsThrowsException
A12.6.8-22
Each detached instance has a persistent identity that can be obtained  
via the static JDOHelper method getObjectId(Object pc).


no
api/persistencemanager/detach/DetachedInstancesGetObjectId
A12.6.8-23
The version of detached instances can be obtained by the static  
JDOHelper method getVersion(Object pc).


no
api/persistencemanager/detach/DetachedInstancesGetObjectId
A12.6.8-24
Each detached instance must be of a class identified in the JDO  
metadata as detachable, or a JDOUserException is thrown with a nested  
JDOUserException for each such instance.


no
api/persistencemanager/detach/DetachNonDetachableThrowsException
A12.6.8-25
The order of instances in the parameter Collection’s iteration  
corresponds to the order of corresponding instances in the returned  
Collection’s iteration.


no
api/persistencemanager/detach/AttachOrderOfDetachedInstances
A12.6.8-26
Changes made to instances while detached are applied to the  
corresponding persistent instances in the cache.


no
api/persistencemanager/detach/AttachAppliesChangesToPersistentInstances
A12.6.8-27
New instances associated with the detached instances are added to the  
persistent instances in the corresponding place.


no
api/persistencemanager/detach/AttachOrderOfDetachedInstances
A12.6.8-28
If it cannot determine if changes were made, then it must mark the  
instance dirty.


no
api/persistencemanager/detach/AttachMarksInstancesDirty
A12.6.8-29
The makeTransactional flag, if set to true, requires the  
implementation to mark transactional the persistent instances  
corresponding to all instances in the closure of the detached graph.


no
api/persistencemanager/detach/AttachMarksInstancesTransactional
A12.6.8-30
If an instance that is not of a detachable class is attempted to be  
attached, a JDOUserException is thrown with a nested JDOUserException  
for each such instance.


no
api/persistencemanager/detach/AttachNonDetachableThrowsException



Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

RE: Detach test case names

Posted by "Matthew T. Adams" <ma...@xcalia.com>.
Thanks, Craig, I am diving into this now.
 
--matthew

-----Original Message-----
From: Craig Russell [mailto:Craig.Russell@Sun.COM] 
Sent: Tuesday, September 20, 2005 3:02 PM
To: jdo-dev@db.apache.org; JDO Expert Group
Subject: Detach test case names


Hi Matthew, 

Here are some test case names for review. This is from the spreadsheet. See
how well it comes out in email.

Craig


A12.6.8-1
We define a new property called DetachOnClose
PersistenceManager.setDetachOnClose(boolean detachOnClose) sets the
DetachOnClose property




no
api/persistencemanager/detach/GetSetDetachOnClose

A12.6.8-2
PersistenceManager.getDetachOnClose() gets the value for the DetachOnClose
property




no
api/persistencemanager/detach/GetSetDetachOnClose

A12.6.8-3
With this flag set to true, after close, the PersistenceManager guarantees
that all persistent instances in the cache behave as detached instances




no
api/persistencemanager/detach/DetachOnCloseCreatesDetachedInstances

A12.6.8-4
can be serialized as detached instances.




no
api/persistencemanager/detach/SerializeCreatesDetachedInstances

A12.6.8-5
restored serialized instances are treated as detached instances.




no
api/persistencemanager/detach/RestoreSerializedInstances

A12.6.8-9
The order of instances in the parameter Collection's iteration corresponds
to the order of corresponding instances in the returned Collection's
iteration.




no
api/persistencemanager/detach/DetachOrderOfDetachedInstances

A12.6.8-10
If a detachCopy method is called with an active transaction, the parameter
Collection of instances is first made persistent, and the reachability
algorithm is run on the instances




no
api/persistencemanager/detach/DetachReachabilityOfDetachedInstances

A12.6.8-11
If a detachCopy method is called outside an active transaction, the
reachability algorithm will not be run; if any transient instances are
reachable via persistent fields, a JDOUserException is thrown for each
persistent instance containing such fields.




no
api/persistencemanager/detach/DetachTransientInstancesOutsideTransactionThro
wsException

A12.6.8-12
If a detachCopy method is called outside an active transaction, the
NontransactionalRead property must be true or JDOUserException is thrown.




no
api/persistencemanager/detach/DetachOutsideTransactionRequiresNontransaction
alRead

A12.6.8-13
For each instance in the parameter Collection, a corresponding detached copy
is created.




no
api/persistencemanager/detach/DetachCreatesCopies

A12.6.8-14
If there are duplicates in the parameter Collection, the corresponding
detached copy is used for each such duplicate.




no
api/persistencemanager/detach/DetachDuplicatesCreatesSingleInstance

A12.6.8-15
Instances in the persistent-new and persistent-dirty state are updated with
their object identity and version




no
api/persistencemanager/detach/DetachNewAndDirtyInstancesAreUpdated

A12.6.8-16
If instances in a deleted state (either persistent-deleted or
persistent-new-deleted) are attempted to be detached, a JDOUserException is
thrown with nested JDOUserExceptions, one for each such instance.




no
api/persistencemanager/detach/DetachDeletedInstancesThrowsException

A12.6.8-17
All fields outside the FetchPlan in the detached instances are set to the
Java language default value for the type of the field.




no
api/persistencemanager/detach/DetachedUnloadedFieldsHaveDefaultValues

A12.6.8-18
Fields in the FetchPlan of primitive and wrapper types are set to their
values from the datastore




no
api/persistencemanager/detach/DetachFieldsLoadedFromDatabase

A12.6.8-19
Fields of references to persistence-capable types are set to the detached
copy corresponding to the persistent instance.




no
api/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances

A12.6.8-20
Fields of Collections and Maps are set to detached SCO instances containing
references to detached copies corresponding to persistent instances in the
datastore.




no
api/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances

A12.6.8-21
While detached, any field access to a field that was not fetched throws
JDODetachedFieldAccessException.




no
api/persistencemanager/detach/AccessingUnloadedFIeldsThrowsException

A12.6.8-22
Each detached instance has a persistent identity that can be obtained via
the static JDOHelper method getObjectId(Object pc).




no
api/persistencemanager/detach/DetachedInstancesGetObjectId

A12.6.8-23
The version of detached instances can be obtained by the static JDOHelper
method getVersion(Object pc).




no
api/persistencemanager/detach/DetachedInstancesGetObjectId

A12.6.8-24
Each detached instance must be of a class identified in the JDO metadata as
detachable, or a JDOUserException is thrown with a nested JDOUserException
for each such instance.




no
api/persistencemanager/detach/DetachNonDetachableThrowsException

A12.6.8-25
The order of instances in the parameter Collection's iteration corresponds
to the order of corresponding instances in the returned Collection's
iteration.




no
api/persistencemanager/detach/AttachOrderOfDetachedInstances

A12.6.8-26
Changes made to instances while detached are applied to the corresponding
persistent instances in the cache.




no
api/persistencemanager/detach/AttachAppliesChangesToPersistentInstances

A12.6.8-27
New instances associated with the detached instances are added to the
persistent instances in the corresponding place.




no
api/persistencemanager/detach/AttachOrderOfDetachedInstances

A12.6.8-28
If it cannot determine if changes were made, then it must mark the instance
dirty.




no
api/persistencemanager/detach/AttachMarksInstancesDirty

A12.6.8-29
The makeTransactional flag, if set to true, requires the implementation to
mark transactional the persistent instances corresponding to all instances
in the closure of the detached graph.




no
api/persistencemanager/detach/AttachMarksInstancesTransactional

A12.6.8-30
If an instance that is not of a detachable class is attempted to be
attached, a JDOUserException is thrown with a nested JDOUserException for
each such instance.




no
api/persistencemanager/detach/AttachNonDetachableThrowsException





Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:Craig.Russell@sun.com

P.S. A good JDO? O, Gasp!

Re: Detach test case names

Posted by Craig Russell <Cr...@Sun.COM>.
Hi Matthew,

You are right. The DetachOnClose is gone, replaced by  
DetachAllOnCommit. The property should also be in the  
PersistenceManagerFactory API.

Please reformat the javadoc so it fits well within 80 characters. If  
your editor allows it, I'd suggest a line break at 75.

I know the rest of the javadoc is all over 80 but for new stuff,  
please keep it less than 80.

Thanks,

Craig


On Sep 21, 2005, at 3:10 PM, Matthew T. Adams wrote:

> As I'm currently working on the first assertion in this list  
> (A12.6.8-1), it looks like the spreadsheet text is outdated -- the  
> property is DetachAllOnCommit, not DetachOnClose.  I recall EG  
> discussions on DetachOnClose -- is that still on the table, or is  
> it gone?
>
> Regardless of the status of DetachOnClose, the property  
> DetachAllOnCommit is not present in the source for  
> PersistenceManager.java.  Further, should this property also be on  
> PersistenceManagerFactory that specifies the default setting for  
> any PMs obtained from the PMF, similar to other properties?   
> Attached is the updated PersistenceManager.java patch -- I have  
> commit priviledges, but I figured I'd send the patch for review  
> before committing it.  Please object soon if you're going to... :)
> --matthew
> -----Original Message-----
> From: Craig Russell [mailto:Craig.Russell@Sun.COM]
> Sent: Tuesday, September 20, 2005 3:02 PM
> To: jdo-dev@db.apache.org; JDO Expert Group
> Subject: Detach test case names
>
> Hi Matthew,
>
> Here are some test case names for review. This is from the  
> spreadsheet. See how well it comes out in email.
>
> Craig
>
> A12.6.8-1
> We define a new property called DetachOnClose  
> PersistenceManager.setDetachOnClose(boolean detachOnClose) sets the  
> DetachOnClose property
>
>
> no
> api/persistencemanager/detach/GetSetDetachOnClose
> A12.6.8-2
> PersistenceManager.getDetachOnClose() gets the value for the  
> DetachOnClose property
>
>
> no
> api/persistencemanager/detach/GetSetDetachOnClose
> A12.6.8-3
> With this flag set to true, after close, the PersistenceManager  
> guarantees that all persistent instances in the cache behave as  
> detached instances
>
>
> no
> api/persistencemanager/detach/DetachOnCloseCreatesDetachedInstances
> A12.6.8-4
> can be serialized as detached instances.
>
>
> no
> api/persistencemanager/detach/SerializeCreatesDetachedInstances
> A12.6.8-5
> restored serialized instances are treated as detached instances.
>
>
> no
> api/persistencemanager/detach/RestoreSerializedInstances
> A12.6.8-9
> The order of instances in the parameter Collection’s iteration  
> corresponds to the order of corresponding instances in the returned  
> Collection’s iteration.
>
>
> no
> api/persistencemanager/detach/DetachOrderOfDetachedInstances
> A12.6.8-10
> If a detachCopy method is called with an active transaction, the  
> parameter Collection of instances is first made persistent, and the  
> reachability algorithm is run on the instances
>
>
> no
> api/persistencemanager/detach/DetachReachabilityOfDetachedInstances
> A12.6.8-11
> If a detachCopy method is called outside an active transaction, the  
> reachability algorithm will not be run; if any transient instances  
> are reachable via persistent fields, a JDOUserException is thrown  
> for each persistent instance containing such fields.
>
>
> no
> api/persistencemanager/detach/ 
> DetachTransientInstancesOutsideTransactionThrowsException
> A12.6.8-12
> If a detachCopy method is called outside an active transaction, the  
> NontransactionalRead property must be true or JDOUserException is  
> thrown.
>
>
> no
> api/persistencemanager/detach/ 
> DetachOutsideTransactionRequiresNontransactionalRead
> A12.6.8-13
> For each instance in the parameter Collection, a corresponding  
> detached copy is created.
>
>
> no
> api/persistencemanager/detach/DetachCreatesCopies
> A12.6.8-14
> If there are duplicates in the parameter Collection, the  
> corresponding detached copy is used for each such duplicate.
>
>
> no
> api/persistencemanager/detach/DetachDuplicatesCreatesSingleInstance
> A12.6.8-15
> Instances in the persistent-new and persistent-dirty state are  
> updated with their object identity and version
>
>
> no
> api/persistencemanager/detach/DetachNewAndDirtyInstancesAreUpdated
> A12.6.8-16
> If instances in a deleted state (either persistent-deleted or  
> persistent-new-deleted) are attempted to be detached, a  
> JDOUserException is thrown with nested JDOUserExceptions, one for  
> each such instance.
>
>
> no
> api/persistencemanager/detach/DetachDeletedInstancesThrowsException
> A12.6.8-17
> All fields outside the FetchPlan in the detached instances are set  
> to the Java language default value for the type of the field.
>
>
> no
> api/persistencemanager/detach/DetachedUnloadedFieldsHaveDefaultValues
> A12.6.8-18
> Fields in the FetchPlan of primitive and wrapper types are set to  
> their values from the datastore
>
>
> no
> api/persistencemanager/detach/DetachFieldsLoadedFromDatabase
> A12.6.8-19
> Fields of references to persistence-capable types are set to the  
> detached copy corresponding to the persistent instance.
>
>
> no
> api/persistencemanager/detach/ 
> DetachRelationshipsSetToDetachedInstances
> A12.6.8-20
> Fields of Collections and Maps are set to detached SCO instances  
> containing references to detached copies corresponding to  
> persistent instances in the datastore.
>
>
> no
> api/persistencemanager/detach/ 
> DetachRelationshipsSetToDetachedInstances
> A12.6.8-21
> While detached, any field access to a field that was not fetched  
> throws JDODetachedFieldAccessException.
>
>
> no
> api/persistencemanager/detach/AccessingUnloadedFIeldsThrowsException
> A12.6.8-22
> Each detached instance has a persistent identity that can be  
> obtained via the static JDOHelper method getObjectId(Object pc).
>
>
> no
> api/persistencemanager/detach/DetachedInstancesGetObjectId
> A12.6.8-23
> The version of detached instances can be obtained by the static  
> JDOHelper method getVersion(Object pc).
>
>
> no
> api/persistencemanager/detach/DetachedInstancesGetObjectId
> A12.6.8-24
> Each detached instance must be of a class identified in the JDO  
> metadata as detachable, or a JDOUserException is thrown with a  
> nested JDOUserException for each such instance.
>
>
> no
> api/persistencemanager/detach/DetachNonDetachableThrowsException
> A12.6.8-25
> The order of instances in the parameter Collection’s iteration  
> corresponds to the order of corresponding instances in the returned  
> Collection’s iteration.
>
>
> no
> api/persistencemanager/detach/AttachOrderOfDetachedInstances
> A12.6.8-26
> Changes made to instances while detached are applied to the  
> corresponding persistent instances in the cache.
>
>
> no
> api/persistencemanager/detach/ 
> AttachAppliesChangesToPersistentInstances
> A12.6.8-27
> New instances associated with the detached instances are added to  
> the persistent instances in the corresponding place.
>
>
> no
> api/persistencemanager/detach/AttachOrderOfDetachedInstances
> A12.6.8-28
> If it cannot determine if changes were made, then it must mark the  
> instance dirty.
>
>
> no
> api/persistencemanager/detach/AttachMarksInstancesDirty
> A12.6.8-29
> The makeTransactional flag, if set to true, requires the  
> implementation to mark transactional the persistent instances  
> corresponding to all instances in the closure of the detached graph.
>
>
> no
> api/persistencemanager/detach/AttachMarksInstancesTransactional
> A12.6.8-30
> If an instance that is not of a detachable class is attempted to be  
> attached, a JDOUserException is thrown with a nested  
> JDOUserException for each such instance.
>
>
> no
> api/persistencemanager/detach/AttachNonDetachableThrowsException
>
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
> <detachOnAllCommit.patch>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: Detach test case names

Posted by Karan Malhi <ka...@gmail.com>.
Hi Craig,

Should i have submitted the maven console patch through JIRA ?

On 9/21/05, Craig Russell <Cr...@sun.com> wrote:
>
> Hi Matthew,
> Now that we have JIRA set up for notifications, the right way to do this
> is:
>
> 1. Oh, the PersistenceManager.java is missing something. Write a JIRA
> issue.
> 2. I know what's needed, comment the JIRA issue (skip this if you already
> know what's wrong).
> 3. Write a patch.
> 4. Attach the patch to the JIRA issue.
> 5. Feedback is sent. Respond on the JIRA issue.
> 6. Everyone has had enough time to comment. A few patch attachments
> decorate the JIRA.
> 7. We're all happy with the patch. Check it in.
>
> JIRA is very good at keeping everyone's comments focused, and at allowing
> examination of the patch contents.
>
> I don't know if a standard for patches is common on other projects, or
> whether it is needed, but I used to create patches as .patch suffix, e.g.
> companyfactory.patch. But this isn't handled well as an email attachment
> so I used .txt as a suffix, e.g. companyfactorypatch.txt. This seems to
> work ok. Now that we can easily download patches from JIRA issues, we might
> try to standardize patch names.
>
> Craig
>
> On Sep 21, 2005, at 3:22 PM, Matthew T. Adams wrote:
>
> One more try with patch attachment, this time using plain text instead of
> HTML...
>
> -----Original Message-----
> From: Matthew T. Adams [mailto:matthew.adams@xcalia.com<ma...@xcalia.com>
> ]
> Sent: Wednesday, September 21, 2005 3:18 PM
> To: jdo-dev@db.apache.org; 'JDO Expert Group'
> Subject: RE: Detach test case names
>
>
> Trying again with patch attachment...
> -----Original Message-----
> From: Matthew T. Adams [mailto:matthew.adams@xcalia.com<ma...@xcalia.com>
> ]
> Sent: Wednesday, September 21, 2005 3:10 PM
> To: jdo-dev@db.apache.org; 'JDO Expert Group'
> Subject: RE: Detach test case names
>
>
> As I'm currently working on the first assertion in this list (A12.6.8-1),
> it
> looks like the spreadsheet text is outdated -- the property is
> DetachAllOnCommit, not DetachOnClose. I recall EG discussions on
> DetachOnClose -- is that still on the table, or is it gone?
>
> Regardless of the status of DetachOnClose, the property DetachAllOnCommit
> is
> not present in the source for PersistenceManager.java. Further, should
> this
> property also be on PersistenceManagerFactory that specifies the default
> setting for any PMs obtained from the PMF, similar to other properties?
> Attached is the updated PersistenceManager.java patch -- I have commit
> priviledges, but I figured I'd send the patch for review before committing
> it. Please object soon if you're going to... :)
>
> --matthew
> -----Original Message-----
> From: Craig Russell [mailto:Craig.Russell@Sun.COM <Cr...@Sun.COM>]
> Sent: Tuesday, September 20, 2005 3:02 PM
> To: jdo-dev@db.apache.org; JDO Expert Group
> Subject: Detach test case names
>
>
> Hi Matthew,
>
>
> Here are some test case names for review. This is from the spreadsheet.
> See
> how well it comes out in email.
>
>
> Craig
>
>
> A12.6.8-1We define a new property called DetachOnClose
> PersistenceManager.setDetachOnClose(boolean detachOnClose) sets the
> DetachOnClose property
>
> noapi/persistencemanager/detach/GetSetDetachOnClose
> A12.6.8-2PersistenceManager.getDetachOnClose() gets the value for the
> DetachOnClose property
>
> noapi/persistencemanager/detach/GetSetDetachOnClose
> A12.6.8-3With this flag set to true, after close, the PersistenceManager
> guarantees that all persistent instances in the cache behave as detached
> instances
>
> noapi/persistencemanager/detach/DetachOnCloseCreatesDetachedInstances
> A12.6.8-4can be serialized as detached instances.
>
> noapi/persistencemanager/detach/SerializeCreatesDetachedInstances
> A12.6.8-5restored serialized instances are treated as detached instances.
>
> noapi/persistencemanager/detach/RestoreSerializedInstances
> A12.6.8-9The order of instances in the parameter Collection's iteration
> corresponds to the order of corresponding instances in the returned
> Collection's iteration.
>
> noapi/persistencemanager/detach/DetachOrderOfDetachedInstances
> A12.6.8-10If a detachCopy method is called with an active transaction, the
> parameter Collection of instances is first made persistent, and the
> reachability algorithm is run on the instances
>
> noapi/persistencemanager/detach/DetachReachabilityOfDetachedInstances
> A12.6.8-11If a detachCopy method is called outside an active transaction,
> the reachability algorithm will not be run; if any transient instances are
> reachable via persistent fields, a JDOUserException is thrown for each
> persistent instance containing such fields.
>
>
> noapi/persistencemanager/detach/DetachTransientInstancesOutsideTransactionTh
> rowsException
> A12.6.8-12If a detachCopy method is called outside an active transaction,
> the NontransactionalRead property must be true or JDOUserException is
> thrown.
>
>
> noapi/persistencemanager/detach/DetachOutsideTransactionRequiresNontransacti
> onalRead
> A12.6.8-13For each instance in the parameter Collection, a corresponding
> detached copy is created.
>
> noapi/persistencemanager/detach/DetachCreatesCopies
> A12.6.8-14If there are duplicates in the parameter Collection, the
> corresponding detached copy is used for each such duplicate.
>
> noapi/persistencemanager/detach/DetachDuplicatesCreatesSingleInstance
> A12.6.8-15Instances in the persistent-new and persistent-dirty state are
> updated with their object identity and version
>
> noapi/persistencemanager/detach/DetachNewAndDirtyInstancesAreUpdated
> A12.6.8-16If instances in a deleted state (either persistent-deleted or
> persistent-new-deleted) are attempted to be detached, a JDOUserException
> is
> thrown with nested JDOUserExceptions, one for each such instance.
>
> noapi/persistencemanager/detach/DetachDeletedInstancesThrowsException
> A12.6.8-17All fields outside the FetchPlan in the detached instances are
> set
> to the Java language default value for the type of the field.
>
> noapi/persistencemanager/detach/DetachedUnloadedFieldsHaveDefaultValues
> A12.6.8-18Fields in the FetchPlan of primitive and wrapper types are set
> to
> their values from the datastore
>
> noapi/persistencemanager/detach/DetachFieldsLoadedFromDatabase
> A12.6.8-19Fields of references to persistence-capable types are set to the
> detached copy corresponding to the persistent instance.
>
> noapi/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances
> A12.6.8-20Fields of Collections and Maps are set to detached SCO instances
> containing references to detached copies corresponding to persistent
> instances in the datastore.
>
> noapi/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances
> A12.6.8-21While detached, any field access to a field that was not fetched
> throws JDODetachedFieldAccessException.
>
> noapi/persistencemanager/detach/AccessingUnloadedFIeldsThrowsException
> A12.6.8-22Each detached instance has a persistent identity that can be
> obtained via the static JDOHelper method getObjectId(Object pc).
>
> noapi/persistencemanager/detach/DetachedInstancesGetObjectId
> A12.6.8-23The version of detached instances can be obtained by the static
> JDOHelper method getVersion(Object pc).
>
> noapi/persistencemanager/detach/DetachedInstancesGetObjectId
> A12.6.8-24Each detached instance must be of a class identified in the JDO
> metadata as detachable, or a JDOUserException is thrown with a nested
> JDOUserException for each such instance.
>
> noapi/persistencemanager/detach/DetachNonDetachableThrowsException
> A12.6.8-25The order of instances in the parameter Collection's iteration
> corresponds to the order of corresponding instances in the returned
> Collection's iteration.
>
> noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
> A12.6.8-26Changes made to instances while detached are applied to the
> corresponding persistent instances in the cache.
>
> noapi/persistencemanager/detach/AttachAppliesChangesToPersistentInstances
> A12.6.8-27New instances associated with the detached instances are added
> to
> the persistent instances in the corresponding place.
>
> noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
> A12.6.8-28If it cannot determine if changes were made, then it must mark
> the
> instance dirty.
>
> noapi/persistencemanager/detach/AttachMarksInstancesDirty
> A12.6.8-29The makeTransactional flag, if set to true, requires the
> implementation to mark transactional the persistent instances
> corresponding
> to all instances in the closure of the detached graph.
>
> noapi/persistencemanager/detach/AttachMarksInstancesTransactional
> A12.6.8-30If an instance that is not of a detachable class is attempted to
> be attached, a JDOUserException is thrown with a nested JDOUserException
> for
> each such instance.
>
> noapi/persistencemanager/detach/AttachNonDetachableThrowsException
>
>
>
>
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com <Cr...@sun.com>
> P.S. A good JDO? O, Gasp!
>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com <Cr...@sun.com>
>
> P.S. A good JDO? O, Gasp!
>
>
>


--
Karan Malhi

Re: Detach test case names

Posted by Michelle Caisse <Mi...@Sun.COM>.
Yes, I had come to the same conclusion.  Step 1 could be filing a JIRA, 
if there isn't already one, with a mention to conduct discussion through 
JIRA.  Then in the step where you submit a patch, you attach it to the JIRA.

If you agree, feel free to make the changes, Karan.

-- Michelle

Craig Russell wrote:

> Hi Karan,
>
> I think it needs to go right on the TCK page under how to write a test 
> case.
>
> Michelle, 
>
> What do you think?
>
> Craig
>
> On Sep 22, 2005, at 4:46 AM, Karan Malhi wrote:
>
>> We should have these instructions on the wiki. I wanted to update the 
>> wiki
>> but was not sure which page to update. I am thinking
>> http://wiki.apache.org/jdo/TechnologyCompatibilityKit could have a 
>> link to
>> "Filing a JIRA issue"
>>
>> On 9/21/05, Craig Russell <Craig.Russell@sun.com 
>> <ma...@sun.com>> wrote:
>>
>>>
>>> Hi Matthew,
>>> Now that we have JIRA set up for notifications, the right way to do this
>>> is:
>>>
>>> 1. Oh, the PersistenceManager.java is missing something. Write a JIRA
>>> issue.
>>> 2. I know what's needed, comment the JIRA issue (skip this if you 
>>> already
>>> know what's wrong).
>>> 3. Write a patch.
>>> 4. Attach the patch to the JIRA issue.
>>> 5. Feedback is sent. Respond on the JIRA issue.
>>> 6. Everyone has had enough time to comment. A few patch attachments
>>> decorate the JIRA.
>>> 7. We're all happy with the patch. Check it in.
>>>
>>> JIRA is very good at keeping everyone's comments focused, and at 
>>> allowing
>>> examination of the patch contents.
>>>
>>> I don't know if a standard for patches is common on other projects, or
>>> whether it is needed, but I used to create patches as .patch suffix, 
>>> e.g.
>>> companyfactory.patch. But this isn't handled well as an email attachment
>>> so I used .txt as a suffix, e.g. companyfactorypatch.txt. This seems to
>>> work ok. Now that we can easily download patches from JIRA issues, 
>>> we might
>>> try to standardize patch names.
>>>
>>> Craig
>>>
>>> On Sep 21, 2005, at 3:22 PM, Matthew T. Adams wrote:
>>>
>>> One more try with patch attachment, this time using plain text 
>>> instead of
>>> HTML...
>>>
>>> -----Original Message-----
>>> From: Matthew T. Adams 
>>> [mailto:matthew.adams@xcalia.com<matthew.adams@xcalia.com 
>>> <ma...@xcalia.com>>
>>> ]
>>> Sent: Wednesday, September 21, 2005 3:18 PM
>>> To: jdo-dev@db.apache.org <ma...@db.apache.org>; 'JDO 
>>> Expert Group'
>>> Subject: RE: Detach test case names
>>>
>>>
>>> Trying again with patch attachment...
>>> -----Original Message-----
>>> From: Matthew T. Adams 
>>> [mailto:matthew.adams@xcalia.com<matthew.adams@xcalia.com 
>>> <ma...@xcalia.com>>
>>> ]
>>> Sent: Wednesday, September 21, 2005 3:10 PM
>>> To: jdo-dev@db.apache.org <ma...@db.apache.org>; 'JDO 
>>> Expert Group'
>>> Subject: RE: Detach test case names
>>>
>>>
>>> As I'm currently working on the first assertion in this list 
>>> (A12.6.8-1),
>>> it
>>> looks like the spreadsheet text is outdated -- the property is
>>> DetachAllOnCommit, not DetachOnClose. I recall EG discussions on
>>> DetachOnClose -- is that still on the table, or is it gone?
>>>
>>> Regardless of the status of DetachOnClose, the property 
>>> DetachAllOnCommit
>>> is
>>> not present in the source for PersistenceManager.java. Further, should
>>> this
>>> property also be on PersistenceManagerFactory that specifies the default
>>> setting for any PMs obtained from the PMF, similar to other properties?
>>> Attached is the updated PersistenceManager.java patch -- I have commit
>>> priviledges, but I figured I'd send the patch for review before 
>>> committing
>>> it. Please object soon if you're going to... :)
>>>
>>> --matthew
>>> -----Original Message-----
>>> From: Craig Russell [mailto:Craig.Russell@Sun.COM 
>>> <Craig.Russell@Sun.COM <ma...@Sun.COM>>]
>>> Sent: Tuesday, September 20, 2005 3:02 PM
>>> To: jdo-dev@db.apache.org <ma...@db.apache.org>; JDO Expert 
>>> Group
>>> Subject: Detach test case names
>>>
>>>
>>> Hi Matthew,
>>>
>>>
>>> Here are some test case names for review. This is from the spreadsheet.
>>> See
>>> how well it comes out in email.
>>>
>>>
>>> Craig
>>>
>>>
>>> A12.6.8-1We define a new property called DetachOnClose
>>> PersistenceManager.setDetachOnClose(boolean detachOnClose) sets the
>>> DetachOnClose property
>>>
>>> noapi/persistencemanager/detach/GetSetDetachOnClose
>>> A12.6.8-2PersistenceManager.getDetachOnClose() gets the value for the
>>> DetachOnClose property
>>>
>>> noapi/persistencemanager/detach/GetSetDetachOnClose
>>> A12.6.8-3With this flag set to true, after close, the PersistenceManager
>>> guarantees that all persistent instances in the cache behave as detached
>>> instances
>>>
>>> noapi/persistencemanager/detach/DetachOnCloseCreatesDetachedInstances
>>> A12.6.8-4can be serialized as detached instances.
>>>
>>> noapi/persistencemanager/detach/SerializeCreatesDetachedInstances
>>> A12.6.8-5restored serialized instances are treated as detached 
>>> instances.
>>>
>>> noapi/persistencemanager/detach/RestoreSerializedInstances
>>> A12.6.8-9The order of instances in the parameter Collection's iteration
>>> corresponds to the order of corresponding instances in the returned
>>> Collection's iteration.
>>>
>>> noapi/persistencemanager/detach/DetachOrderOfDetachedInstances
>>> A12.6.8-10If a detachCopy method is called with an active 
>>> transaction, the
>>> parameter Collection of instances is first made persistent, and the
>>> reachability algorithm is run on the instances
>>>
>>> noapi/persistencemanager/detach/DetachReachabilityOfDetachedInstances
>>> A12.6.8-11If a detachCopy method is called outside an active 
>>> transaction,
>>> the reachability algorithm will not be run; if any transient 
>>> instances are
>>> reachable via persistent fields, a JDOUserException is thrown for each
>>> persistent instance containing such fields.
>>>
>>>
>>> noapi/persistencemanager/detach/DetachTransientInstancesOutsideTransactionTh
>>> rowsException
>>> A12.6.8-12If a detachCopy method is called outside an active 
>>> transaction,
>>> the NontransactionalRead property must be true or JDOUserException is
>>> thrown.
>>>
>>>
>>> noapi/persistencemanager/detach/DetachOutsideTransactionRequiresNontransacti
>>> onalRead
>>> A12.6.8-13For each instance in the parameter Collection, a corresponding
>>> detached copy is created.
>>>
>>> noapi/persistencemanager/detach/DetachCreatesCopies
>>> A12.6.8-14If there are duplicates in the parameter Collection, the
>>> corresponding detached copy is used for each such duplicate.
>>>
>>> noapi/persistencemanager/detach/DetachDuplicatesCreatesSingleInstance
>>> A12.6.8-15Instances in the persistent-new and persistent-dirty state are
>>> updated with their object identity and version
>>>
>>> noapi/persistencemanager/detach/DetachNewAndDirtyInstancesAreUpdated
>>> A12.6.8-16If instances in a deleted state (either persistent-deleted or
>>> persistent-new-deleted) are attempted to be detached, a JDOUserException
>>> is
>>> thrown with nested JDOUserExceptions, one for each such instance.
>>>
>>> noapi/persistencemanager/detach/DetachDeletedInstancesThrowsException
>>> A12.6.8-17All fields outside the FetchPlan in the detached instances are
>>> set
>>> to the Java language default value for the type of the field.
>>>
>>> noapi/persistencemanager/detach/DetachedUnloadedFieldsHaveDefaultValues
>>> A12.6.8-18Fields in the FetchPlan of primitive and wrapper types are set
>>> to
>>> their values from the datastore
>>>
>>> noapi/persistencemanager/detach/DetachFieldsLoadedFromDatabase
>>> A12.6.8-19Fields of references to persistence-capable types are set 
>>> to the
>>> detached copy corresponding to the persistent instance.
>>>
>>> noapi/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances
>>> A12.6.8-20Fields of Collections and Maps are set to detached SCO 
>>> instances
>>> containing references to detached copies corresponding to persistent
>>> instances in the datastore.
>>>
>>> noapi/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances
>>> A12.6.8-21While detached, any field access to a field that was not 
>>> fetched
>>> throws JDODetachedFieldAccessException.
>>>
>>> noapi/persistencemanager/detach/AccessingUnloadedFIeldsThrowsException
>>> A12.6.8-22Each detached instance has a persistent identity that can be
>>> obtained via the static JDOHelper method getObjectId(Object pc).
>>>
>>> noapi/persistencemanager/detach/DetachedInstancesGetObjectId
>>> A12.6.8-23The version of detached instances can be obtained by the 
>>> static
>>> JDOHelper method getVersion(Object pc).
>>>
>>> noapi/persistencemanager/detach/DetachedInstancesGetObjectId
>>> A12.6.8-24Each detached instance must be of a class identified in 
>>> the JDO
>>> metadata as detachable, or a JDOUserException is thrown with a nested
>>> JDOUserException for each such instance.
>>>
>>> noapi/persistencemanager/detach/DetachNonDetachableThrowsException
>>> A12.6.8-25The order of instances in the parameter Collection's iteration
>>> corresponds to the order of corresponding instances in the returned
>>> Collection's iteration.
>>>
>>> noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
>>> A12.6.8-26Changes made to instances while detached are applied to the
>>> corresponding persistent instances in the cache.
>>>
>>> noapi/persistencemanager/detach/AttachAppliesChangesToPersistentInstances
>>> A12.6.8-27New instances associated with the detached instances are added
>>> to
>>> the persistent instances in the corresponding place.
>>>
>>> noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
>>> A12.6.8-28If it cannot determine if changes were made, then it must mark
>>> the
>>> instance dirty.
>>>
>>> noapi/persistencemanager/detach/AttachMarksInstancesDirty
>>> A12.6.8-29The makeTransactional flag, if set to true, requires the
>>> implementation to mark transactional the persistent instances
>>> corresponding
>>> to all instances in the closure of the detached graph.
>>>
>>> noapi/persistencemanager/detach/AttachMarksInstancesTransactional
>>> A12.6.8-30If an instance that is not of a detachable class is 
>>> attempted to
>>> be attached, a JDOUserException is thrown with a nested JDOUserException
>>> for
>>> each such instance.
>>>
>>> noapi/persistencemanager/detach/AttachNonDetachableThrowsException
>>>
>>>
>>>
>>>
>>>
>>>
>>> Craig Russell
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>> 408 276-5638 mailto:Craig.Russell@sun.com <Craig.Russell@sun.com 
>>> <ma...@sun.com>>
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>> Craig Russell
>>>
>>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>>>
>>> 408 276-5638 mailto:Craig.Russell@sun.com <Craig.Russell@sun.com 
>>> <ma...@sun.com>>
>>>
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Karan Malhi
>>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>

Re: Detach test case names

Posted by Craig Russell <Cr...@Sun.COM>.
Hi Karan,

I think it needs to go right on the TCK page under how to write a  
test case.

Michelle,

What do you think?

Craig

On Sep 22, 2005, at 4:46 AM, Karan Malhi wrote:

> We should have these instructions on the wiki. I wanted to update  
> the wiki
> but was not sure which page to update. I am thinking
> http://wiki.apache.org/jdo/TechnologyCompatibilityKit could have a  
> link to
> "Filing a JIRA issue"
>
> On 9/21/05, Craig Russell <Cr...@sun.com> wrote:
>
>>
>> Hi Matthew,
>> Now that we have JIRA set up for notifications, the right way to  
>> do this
>> is:
>>
>> 1. Oh, the PersistenceManager.java is missing something. Write a JIRA
>> issue.
>> 2. I know what's needed, comment the JIRA issue (skip this if you  
>> already
>> know what's wrong).
>> 3. Write a patch.
>> 4. Attach the patch to the JIRA issue.
>> 5. Feedback is sent. Respond on the JIRA issue.
>> 6. Everyone has had enough time to comment. A few patch attachments
>> decorate the JIRA.
>> 7. We're all happy with the patch. Check it in.
>>
>> JIRA is very good at keeping everyone's comments focused, and at  
>> allowing
>> examination of the patch contents.
>>
>> I don't know if a standard for patches is common on other  
>> projects, or
>> whether it is needed, but I used to create patches as .patch  
>> suffix, e.g.
>> companyfactory.patch. But this isn't handled well as an email  
>> attachment
>> so I used .txt as a suffix, e.g. companyfactorypatch.txt. This  
>> seems to
>> work ok. Now that we can easily download patches from JIRA issues,  
>> we might
>> try to standardize patch names.
>>
>> Craig
>>
>> On Sep 21, 2005, at 3:22 PM, Matthew T. Adams wrote:
>>
>> One more try with patch attachment, this time using plain text  
>> instead of
>> HTML...
>>
>> -----Original Message-----
>> From: Matthew T. Adams  
>> [mailto:matthew.adams@xcalia.com<ma...@xcalia.com>
>> ]
>> Sent: Wednesday, September 21, 2005 3:18 PM
>> To: jdo-dev@db.apache.org; 'JDO Expert Group'
>> Subject: RE: Detach test case names
>>
>>
>> Trying again with patch attachment...
>> -----Original Message-----
>> From: Matthew T. Adams  
>> [mailto:matthew.adams@xcalia.com<ma...@xcalia.com>
>> ]
>> Sent: Wednesday, September 21, 2005 3:10 PM
>> To: jdo-dev@db.apache.org; 'JDO Expert Group'
>> Subject: RE: Detach test case names
>>
>>
>> As I'm currently working on the first assertion in this list  
>> (A12.6.8-1),
>> it
>> looks like the spreadsheet text is outdated -- the property is
>> DetachAllOnCommit, not DetachOnClose. I recall EG discussions on
>> DetachOnClose -- is that still on the table, or is it gone?
>>
>> Regardless of the status of DetachOnClose, the property  
>> DetachAllOnCommit
>> is
>> not present in the source for PersistenceManager.java. Further,  
>> should
>> this
>> property also be on PersistenceManagerFactory that specifies the  
>> default
>> setting for any PMs obtained from the PMF, similar to other  
>> properties?
>> Attached is the updated PersistenceManager.java patch -- I have  
>> commit
>> priviledges, but I figured I'd send the patch for review before  
>> committing
>> it. Please object soon if you're going to... :)
>>
>> --matthew
>> -----Original Message-----
>> From: Craig Russell [mailto:Craig.Russell@Sun.COM  
>> <Cr...@Sun.COM>]
>> Sent: Tuesday, September 20, 2005 3:02 PM
>> To: jdo-dev@db.apache.org; JDO Expert Group
>> Subject: Detach test case names
>>
>>
>> Hi Matthew,
>>
>>
>> Here are some test case names for review. This is from the  
>> spreadsheet.
>> See
>> how well it comes out in email.
>>
>>
>> Craig
>>
>>
>> A12.6.8-1We define a new property called DetachOnClose
>> PersistenceManager.setDetachOnClose(boolean detachOnClose) sets the
>> DetachOnClose property
>>
>> noapi/persistencemanager/detach/GetSetDetachOnClose
>> A12.6.8-2PersistenceManager.getDetachOnClose() gets the value for the
>> DetachOnClose property
>>
>> noapi/persistencemanager/detach/GetSetDetachOnClose
>> A12.6.8-3With this flag set to true, after close, the  
>> PersistenceManager
>> guarantees that all persistent instances in the cache behave as  
>> detached
>> instances
>>
>> noapi/persistencemanager/detach/DetachOnCloseCreatesDetachedInstances
>> A12.6.8-4can be serialized as detached instances.
>>
>> noapi/persistencemanager/detach/SerializeCreatesDetachedInstances
>> A12.6.8-5restored serialized instances are treated as detached  
>> instances.
>>
>> noapi/persistencemanager/detach/RestoreSerializedInstances
>> A12.6.8-9The order of instances in the parameter Collection's  
>> iteration
>> corresponds to the order of corresponding instances in the returned
>> Collection's iteration.
>>
>> noapi/persistencemanager/detach/DetachOrderOfDetachedInstances
>> A12.6.8-10If a detachCopy method is called with an active  
>> transaction, the
>> parameter Collection of instances is first made persistent, and the
>> reachability algorithm is run on the instances
>>
>> noapi/persistencemanager/detach/DetachReachabilityOfDetachedInstances
>> A12.6.8-11If a detachCopy method is called outside an active  
>> transaction,
>> the reachability algorithm will not be run; if any transient  
>> instances are
>> reachable via persistent fields, a JDOUserException is thrown for  
>> each
>> persistent instance containing such fields.
>>
>>
>> noapi/persistencemanager/detach/ 
>> DetachTransientInstancesOutsideTransactionTh
>> rowsException
>> A12.6.8-12If a detachCopy method is called outside an active  
>> transaction,
>> the NontransactionalRead property must be true or JDOUserException is
>> thrown.
>>
>>
>> noapi/persistencemanager/detach/ 
>> DetachOutsideTransactionRequiresNontransacti
>> onalRead
>> A12.6.8-13For each instance in the parameter Collection, a  
>> corresponding
>> detached copy is created.
>>
>> noapi/persistencemanager/detach/DetachCreatesCopies
>> A12.6.8-14If there are duplicates in the parameter Collection, the
>> corresponding detached copy is used for each such duplicate.
>>
>> noapi/persistencemanager/detach/DetachDuplicatesCreatesSingleInstance
>> A12.6.8-15Instances in the persistent-new and persistent-dirty  
>> state are
>> updated with their object identity and version
>>
>> noapi/persistencemanager/detach/DetachNewAndDirtyInstancesAreUpdated
>> A12.6.8-16If instances in a deleted state (either persistent- 
>> deleted or
>> persistent-new-deleted) are attempted to be detached, a  
>> JDOUserException
>> is
>> thrown with nested JDOUserExceptions, one for each such instance.
>>
>> noapi/persistencemanager/detach/DetachDeletedInstancesThrowsException
>> A12.6.8-17All fields outside the FetchPlan in the detached  
>> instances are
>> set
>> to the Java language default value for the type of the field.
>>
>> noapi/persistencemanager/detach/ 
>> DetachedUnloadedFieldsHaveDefaultValues
>> A12.6.8-18Fields in the FetchPlan of primitive and wrapper types  
>> are set
>> to
>> their values from the datastore
>>
>> noapi/persistencemanager/detach/DetachFieldsLoadedFromDatabase
>> A12.6.8-19Fields of references to persistence-capable types are  
>> set to the
>> detached copy corresponding to the persistent instance.
>>
>> noapi/persistencemanager/detach/ 
>> DetachRelationshipsSetToDetachedInstances
>> A12.6.8-20Fields of Collections and Maps are set to detached SCO  
>> instances
>> containing references to detached copies corresponding to persistent
>> instances in the datastore.
>>
>> noapi/persistencemanager/detach/ 
>> DetachRelationshipsSetToDetachedInstances
>> A12.6.8-21While detached, any field access to a field that was not  
>> fetched
>> throws JDODetachedFieldAccessException.
>>
>> noapi/persistencemanager/detach/ 
>> AccessingUnloadedFIeldsThrowsException
>> A12.6.8-22Each detached instance has a persistent identity that  
>> can be
>> obtained via the static JDOHelper method getObjectId(Object pc).
>>
>> noapi/persistencemanager/detach/DetachedInstancesGetObjectId
>> A12.6.8-23The version of detached instances can be obtained by the  
>> static
>> JDOHelper method getVersion(Object pc).
>>
>> noapi/persistencemanager/detach/DetachedInstancesGetObjectId
>> A12.6.8-24Each detached instance must be of a class identified in  
>> the JDO
>> metadata as detachable, or a JDOUserException is thrown with a nested
>> JDOUserException for each such instance.
>>
>> noapi/persistencemanager/detach/DetachNonDetachableThrowsException
>> A12.6.8-25The order of instances in the parameter Collection's  
>> iteration
>> corresponds to the order of corresponding instances in the returned
>> Collection's iteration.
>>
>> noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
>> A12.6.8-26Changes made to instances while detached are applied to the
>> corresponding persistent instances in the cache.
>>
>> noapi/persistencemanager/detach/ 
>> AttachAppliesChangesToPersistentInstances
>> A12.6.8-27New instances associated with the detached instances are  
>> added
>> to
>> the persistent instances in the corresponding place.
>>
>> noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
>> A12.6.8-28If it cannot determine if changes were made, then it  
>> must mark
>> the
>> instance dirty.
>>
>> noapi/persistencemanager/detach/AttachMarksInstancesDirty
>> A12.6.8-29The makeTransactional flag, if set to true, requires the
>> implementation to mark transactional the persistent instances
>> corresponding
>> to all instances in the closure of the detached graph.
>>
>> noapi/persistencemanager/detach/AttachMarksInstancesTransactional
>> A12.6.8-30If an instance that is not of a detachable class is  
>> attempted to
>> be attached, a JDOUserException is thrown with a nested  
>> JDOUserException
>> for
>> each such instance.
>>
>> noapi/persistencemanager/detach/AttachNonDetachableThrowsException
>>
>>
>>
>>
>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com <Cr...@sun.com>
>> P.S. A good JDO? O, Gasp!
>>
>>
>> Craig Russell
>>
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>>
>> 408 276-5638 mailto:Craig.Russell@sun.com <Cr...@sun.com>
>>
>> P.S. A good JDO? O, Gasp!
>>
>>
>>
>>
>
>
> --
> Karan Malhi
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: Detach test case names

Posted by Karan Malhi <ka...@gmail.com>.
We should have these instructions on the wiki. I wanted to update the wiki
but was not sure which page to update. I am thinking
http://wiki.apache.org/jdo/TechnologyCompatibilityKit could have a link to
"Filing a JIRA issue"

On 9/21/05, Craig Russell <Cr...@sun.com> wrote:
>
> Hi Matthew,
> Now that we have JIRA set up for notifications, the right way to do this
> is:
>
> 1. Oh, the PersistenceManager.java is missing something. Write a JIRA
> issue.
> 2. I know what's needed, comment the JIRA issue (skip this if you already
> know what's wrong).
> 3. Write a patch.
> 4. Attach the patch to the JIRA issue.
> 5. Feedback is sent. Respond on the JIRA issue.
> 6. Everyone has had enough time to comment. A few patch attachments
> decorate the JIRA.
> 7. We're all happy with the patch. Check it in.
>
> JIRA is very good at keeping everyone's comments focused, and at allowing
> examination of the patch contents.
>
> I don't know if a standard for patches is common on other projects, or
> whether it is needed, but I used to create patches as .patch suffix, e.g.
> companyfactory.patch. But this isn't handled well as an email attachment
> so I used .txt as a suffix, e.g. companyfactorypatch.txt. This seems to
> work ok. Now that we can easily download patches from JIRA issues, we might
> try to standardize patch names.
>
> Craig
>
> On Sep 21, 2005, at 3:22 PM, Matthew T. Adams wrote:
>
> One more try with patch attachment, this time using plain text instead of
> HTML...
>
> -----Original Message-----
> From: Matthew T. Adams [mailto:matthew.adams@xcalia.com<ma...@xcalia.com>
> ]
> Sent: Wednesday, September 21, 2005 3:18 PM
> To: jdo-dev@db.apache.org; 'JDO Expert Group'
> Subject: RE: Detach test case names
>
>
> Trying again with patch attachment...
> -----Original Message-----
> From: Matthew T. Adams [mailto:matthew.adams@xcalia.com<ma...@xcalia.com>
> ]
> Sent: Wednesday, September 21, 2005 3:10 PM
> To: jdo-dev@db.apache.org; 'JDO Expert Group'
> Subject: RE: Detach test case names
>
>
> As I'm currently working on the first assertion in this list (A12.6.8-1),
> it
> looks like the spreadsheet text is outdated -- the property is
> DetachAllOnCommit, not DetachOnClose. I recall EG discussions on
> DetachOnClose -- is that still on the table, or is it gone?
>
> Regardless of the status of DetachOnClose, the property DetachAllOnCommit
> is
> not present in the source for PersistenceManager.java. Further, should
> this
> property also be on PersistenceManagerFactory that specifies the default
> setting for any PMs obtained from the PMF, similar to other properties?
> Attached is the updated PersistenceManager.java patch -- I have commit
> priviledges, but I figured I'd send the patch for review before committing
> it. Please object soon if you're going to... :)
>
> --matthew
> -----Original Message-----
> From: Craig Russell [mailto:Craig.Russell@Sun.COM <Cr...@Sun.COM>]
> Sent: Tuesday, September 20, 2005 3:02 PM
> To: jdo-dev@db.apache.org; JDO Expert Group
> Subject: Detach test case names
>
>
> Hi Matthew,
>
>
> Here are some test case names for review. This is from the spreadsheet.
> See
> how well it comes out in email.
>
>
> Craig
>
>
> A12.6.8-1We define a new property called DetachOnClose
> PersistenceManager.setDetachOnClose(boolean detachOnClose) sets the
> DetachOnClose property
>
> noapi/persistencemanager/detach/GetSetDetachOnClose
> A12.6.8-2PersistenceManager.getDetachOnClose() gets the value for the
> DetachOnClose property
>
> noapi/persistencemanager/detach/GetSetDetachOnClose
> A12.6.8-3With this flag set to true, after close, the PersistenceManager
> guarantees that all persistent instances in the cache behave as detached
> instances
>
> noapi/persistencemanager/detach/DetachOnCloseCreatesDetachedInstances
> A12.6.8-4can be serialized as detached instances.
>
> noapi/persistencemanager/detach/SerializeCreatesDetachedInstances
> A12.6.8-5restored serialized instances are treated as detached instances.
>
> noapi/persistencemanager/detach/RestoreSerializedInstances
> A12.6.8-9The order of instances in the parameter Collection's iteration
> corresponds to the order of corresponding instances in the returned
> Collection's iteration.
>
> noapi/persistencemanager/detach/DetachOrderOfDetachedInstances
> A12.6.8-10If a detachCopy method is called with an active transaction, the
> parameter Collection of instances is first made persistent, and the
> reachability algorithm is run on the instances
>
> noapi/persistencemanager/detach/DetachReachabilityOfDetachedInstances
> A12.6.8-11If a detachCopy method is called outside an active transaction,
> the reachability algorithm will not be run; if any transient instances are
> reachable via persistent fields, a JDOUserException is thrown for each
> persistent instance containing such fields.
>
>
> noapi/persistencemanager/detach/DetachTransientInstancesOutsideTransactionTh
> rowsException
> A12.6.8-12If a detachCopy method is called outside an active transaction,
> the NontransactionalRead property must be true or JDOUserException is
> thrown.
>
>
> noapi/persistencemanager/detach/DetachOutsideTransactionRequiresNontransacti
> onalRead
> A12.6.8-13For each instance in the parameter Collection, a corresponding
> detached copy is created.
>
> noapi/persistencemanager/detach/DetachCreatesCopies
> A12.6.8-14If there are duplicates in the parameter Collection, the
> corresponding detached copy is used for each such duplicate.
>
> noapi/persistencemanager/detach/DetachDuplicatesCreatesSingleInstance
> A12.6.8-15Instances in the persistent-new and persistent-dirty state are
> updated with their object identity and version
>
> noapi/persistencemanager/detach/DetachNewAndDirtyInstancesAreUpdated
> A12.6.8-16If instances in a deleted state (either persistent-deleted or
> persistent-new-deleted) are attempted to be detached, a JDOUserException
> is
> thrown with nested JDOUserExceptions, one for each such instance.
>
> noapi/persistencemanager/detach/DetachDeletedInstancesThrowsException
> A12.6.8-17All fields outside the FetchPlan in the detached instances are
> set
> to the Java language default value for the type of the field.
>
> noapi/persistencemanager/detach/DetachedUnloadedFieldsHaveDefaultValues
> A12.6.8-18Fields in the FetchPlan of primitive and wrapper types are set
> to
> their values from the datastore
>
> noapi/persistencemanager/detach/DetachFieldsLoadedFromDatabase
> A12.6.8-19Fields of references to persistence-capable types are set to the
> detached copy corresponding to the persistent instance.
>
> noapi/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances
> A12.6.8-20Fields of Collections and Maps are set to detached SCO instances
> containing references to detached copies corresponding to persistent
> instances in the datastore.
>
> noapi/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances
> A12.6.8-21While detached, any field access to a field that was not fetched
> throws JDODetachedFieldAccessException.
>
> noapi/persistencemanager/detach/AccessingUnloadedFIeldsThrowsException
> A12.6.8-22Each detached instance has a persistent identity that can be
> obtained via the static JDOHelper method getObjectId(Object pc).
>
> noapi/persistencemanager/detach/DetachedInstancesGetObjectId
> A12.6.8-23The version of detached instances can be obtained by the static
> JDOHelper method getVersion(Object pc).
>
> noapi/persistencemanager/detach/DetachedInstancesGetObjectId
> A12.6.8-24Each detached instance must be of a class identified in the JDO
> metadata as detachable, or a JDOUserException is thrown with a nested
> JDOUserException for each such instance.
>
> noapi/persistencemanager/detach/DetachNonDetachableThrowsException
> A12.6.8-25The order of instances in the parameter Collection's iteration
> corresponds to the order of corresponding instances in the returned
> Collection's iteration.
>
> noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
> A12.6.8-26Changes made to instances while detached are applied to the
> corresponding persistent instances in the cache.
>
> noapi/persistencemanager/detach/AttachAppliesChangesToPersistentInstances
> A12.6.8-27New instances associated with the detached instances are added
> to
> the persistent instances in the corresponding place.
>
> noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
> A12.6.8-28If it cannot determine if changes were made, then it must mark
> the
> instance dirty.
>
> noapi/persistencemanager/detach/AttachMarksInstancesDirty
> A12.6.8-29The makeTransactional flag, if set to true, requires the
> implementation to mark transactional the persistent instances
> corresponding
> to all instances in the closure of the detached graph.
>
> noapi/persistencemanager/detach/AttachMarksInstancesTransactional
> A12.6.8-30If an instance that is not of a detachable class is attempted to
> be attached, a JDOUserException is thrown with a nested JDOUserException
> for
> each such instance.
>
> noapi/persistencemanager/detach/AttachNonDetachableThrowsException
>
>
>
>
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com <Cr...@sun.com>
> P.S. A good JDO? O, Gasp!
>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com <Cr...@sun.com>
>
> P.S. A good JDO? O, Gasp!
>
>
>


--
Karan Malhi

Re: Detach test case names

Posted by Craig Russell <Cr...@Sun.COM>.
Hi Matthew,

Now that we have JIRA set up for notifications, the right way to do  
this is:

1. Oh, the PersistenceManager.java is missing something. Write a JIRA  
issue.
2. I know what's needed, comment the JIRA issue (skip this if you  
already know what's wrong).
3. Write a patch.
4. Attach the patch to the JIRA issue.
5. Feedback is sent. Respond on the JIRA issue.
6. Everyone has had enough time to comment. A few patch attachments  
decorate the JIRA.
7. We're all happy with the patch. Check it in.

JIRA is very good at keeping everyone's comments focused, and at  
allowing examination of the patch contents.

I don't know if a standard for patches is common on other projects,  
or whether it is needed, but I used to create patches as .patch  
suffix, e.g. companyfactory.patch. But this isn't handled well as an  
email attachment so I used .txt as a suffix, e.g.  
companyfactorypatch.txt. This seems to work ok. Now that we can  
easily download patches from JIRA issues, we might try to standardize  
patch names.

Craig

On Sep 21, 2005, at 3:22 PM, Matthew T. Adams wrote:

> One more try with patch attachment, this time using plain text  
> instead of
> HTML...
>
> -----Original Message-----
> From: Matthew T. Adams [mailto:matthew.adams@xcalia.com]
> Sent: Wednesday, September 21, 2005 3:18 PM
> To: jdo-dev@db.apache.org; 'JDO Expert Group'
> Subject: RE: Detach test case names
>
>
> Trying again with patch attachment...
> -----Original Message-----
> From: Matthew T. Adams [mailto:matthew.adams@xcalia.com]
> Sent: Wednesday, September 21, 2005 3:10 PM
> To: jdo-dev@db.apache.org; 'JDO Expert Group'
> Subject: RE: Detach test case names
>
>
> As I'm currently working on the first assertion in this list  
> (A12.6.8-1), it
> looks like the spreadsheet text is outdated -- the property is
> DetachAllOnCommit, not DetachOnClose.  I recall EG discussions on
> DetachOnClose -- is that still on the table, or is it gone?
>
> Regardless of the status of DetachOnClose, the property  
> DetachAllOnCommit is
> not present in the source for PersistenceManager.java.  Further,  
> should this
> property also be on PersistenceManagerFactory that specifies the  
> default
> setting for any PMs obtained from the PMF, similar to other  
> properties?
> Attached is the updated PersistenceManager.java patch -- I have commit
> priviledges, but I figured I'd send the patch for review before  
> committing
> it.  Please object soon if you're going to... :)
>
> --matthew
> -----Original Message-----
> From: Craig Russell [mailto:Craig.Russell@Sun.COM]
> Sent: Tuesday, September 20, 2005 3:02 PM
> To: jdo-dev@db.apache.org; JDO Expert Group
> Subject: Detach test case names
>
>
> Hi Matthew,
>
>
> Here are some test case names for review. This is from the  
> spreadsheet. See
> how well it comes out in email.
>
>
> Craig
>
>
> A12.6.8-1We define a new property called DetachOnClose
> PersistenceManager.setDetachOnClose(boolean detachOnClose) sets the
> DetachOnClose property
>
> noapi/persistencemanager/detach/GetSetDetachOnClose
> A12.6.8-2PersistenceManager.getDetachOnClose() gets the value for the
> DetachOnClose property
>
> noapi/persistencemanager/detach/GetSetDetachOnClose
> A12.6.8-3With this flag set to true, after close, the  
> PersistenceManager
> guarantees that all persistent instances in the cache behave as  
> detached
> instances
>
> noapi/persistencemanager/detach/DetachOnCloseCreatesDetachedInstances
> A12.6.8-4can be serialized as detached instances.
>
> noapi/persistencemanager/detach/SerializeCreatesDetachedInstances
> A12.6.8-5restored serialized instances are treated as detached  
> instances.
>
> noapi/persistencemanager/detach/RestoreSerializedInstances
> A12.6.8-9The order of instances in the parameter Collection's  
> iteration
> corresponds to the order of corresponding instances in the returned
> Collection's iteration.
>
> noapi/persistencemanager/detach/DetachOrderOfDetachedInstances
> A12.6.8-10If a detachCopy method is called with an active  
> transaction, the
> parameter Collection of instances is first made persistent, and the
> reachability algorithm is run on the instances
>
> noapi/persistencemanager/detach/DetachReachabilityOfDetachedInstances
> A12.6.8-11If a detachCopy method is called outside an active  
> transaction,
> the reachability algorithm will not be run; if any transient  
> instances are
> reachable via persistent fields, a JDOUserException is thrown for each
> persistent instance containing such fields.
>
> noapi/persistencemanager/detach/ 
> DetachTransientInstancesOutsideTransactionTh
> rowsException
> A12.6.8-12If a detachCopy method is called outside an active  
> transaction,
> the NontransactionalRead property must be true or JDOUserException is
> thrown.
>
> noapi/persistencemanager/detach/ 
> DetachOutsideTransactionRequiresNontransacti
> onalRead
> A12.6.8-13For each instance in the parameter Collection, a  
> corresponding
> detached copy is created.
>
> noapi/persistencemanager/detach/DetachCreatesCopies
> A12.6.8-14If there are duplicates in the parameter Collection, the
> corresponding detached copy is used for each such duplicate.
>
> noapi/persistencemanager/detach/DetachDuplicatesCreatesSingleInstance
> A12.6.8-15Instances in the persistent-new and persistent-dirty  
> state are
> updated with their object identity and version
>
> noapi/persistencemanager/detach/DetachNewAndDirtyInstancesAreUpdated
> A12.6.8-16If instances in a deleted state (either persistent- 
> deleted or
> persistent-new-deleted) are attempted to be detached, a  
> JDOUserException is
> thrown with nested JDOUserExceptions, one for each such instance.
>
> noapi/persistencemanager/detach/DetachDeletedInstancesThrowsException
> A12.6.8-17All fields outside the FetchPlan in the detached  
> instances are set
> to the Java language default value for the type of the field.
>
> noapi/persistencemanager/detach/ 
> DetachedUnloadedFieldsHaveDefaultValues
> A12.6.8-18Fields in the FetchPlan of primitive and wrapper types  
> are set to
> their values from the datastore
>
> noapi/persistencemanager/detach/DetachFieldsLoadedFromDatabase
> A12.6.8-19Fields of references to persistence-capable types are set  
> to the
> detached copy corresponding to the persistent instance.
>
> noapi/persistencemanager/detach/ 
> DetachRelationshipsSetToDetachedInstances
> A12.6.8-20Fields of Collections and Maps are set to detached SCO  
> instances
> containing references to detached copies corresponding to persistent
> instances in the datastore.
>
> noapi/persistencemanager/detach/ 
> DetachRelationshipsSetToDetachedInstances
> A12.6.8-21While detached, any field access to a field that was not  
> fetched
> throws JDODetachedFieldAccessException.
>
> noapi/persistencemanager/detach/AccessingUnloadedFIeldsThrowsException
> A12.6.8-22Each detached instance has a persistent identity that can be
> obtained via the static JDOHelper method getObjectId(Object pc).
>
> noapi/persistencemanager/detach/DetachedInstancesGetObjectId
> A12.6.8-23The version of detached instances can be obtained by the  
> static
> JDOHelper method getVersion(Object pc).
>
> noapi/persistencemanager/detach/DetachedInstancesGetObjectId
> A12.6.8-24Each detached instance must be of a class identified in  
> the JDO
> metadata as detachable, or a JDOUserException is thrown with a nested
> JDOUserException for each such instance.
>
> noapi/persistencemanager/detach/DetachNonDetachableThrowsException
> A12.6.8-25The order of instances in the parameter Collection's  
> iteration
> corresponds to the order of corresponding instances in the returned
> Collection's iteration.
>
> noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
> A12.6.8-26Changes made to instances while detached are applied to the
> corresponding persistent instances in the cache.
>
> noapi/persistencemanager/detach/ 
> AttachAppliesChangesToPersistentInstances
> A12.6.8-27New instances associated with the detached instances are  
> added to
> the persistent instances in the corresponding place.
>
> noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
> A12.6.8-28If it cannot determine if changes were made, then it must  
> mark the
> instance dirty.
>
> noapi/persistencemanager/detach/AttachMarksInstancesDirty
> A12.6.8-29The makeTransactional flag, if set to true, requires the
> implementation to mark transactional the persistent instances  
> corresponding
> to all instances in the closure of the detached graph.
>
> noapi/persistencemanager/detach/AttachMarksInstancesTransactional
> A12.6.8-30If an instance that is not of a detachable class is  
> attempted to
> be attached, a JDOUserException is thrown with a nested  
> JDOUserException for
> each such instance.
>
> noapi/persistencemanager/detach/AttachNonDetachableThrowsException
>
>
>
>
>
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

RE: Detach test case names

Posted by "Matthew T. Adams" <ma...@xcalia.com>.
One more try with patch attachment, this time using plain text instead of
HTML...

-----Original Message-----
From: Matthew T. Adams [mailto:matthew.adams@xcalia.com] 
Sent: Wednesday, September 21, 2005 3:18 PM
To: jdo-dev@db.apache.org; 'JDO Expert Group'
Subject: RE: Detach test case names


Trying again with patch attachment...
-----Original Message-----
From: Matthew T. Adams [mailto:matthew.adams@xcalia.com] 
Sent: Wednesday, September 21, 2005 3:10 PM
To: jdo-dev@db.apache.org; 'JDO Expert Group'
Subject: RE: Detach test case names


As I'm currently working on the first assertion in this list (A12.6.8-1), it
looks like the spreadsheet text is outdated -- the property is
DetachAllOnCommit, not DetachOnClose.  I recall EG discussions on
DetachOnClose -- is that still on the table, or is it gone?

Regardless of the status of DetachOnClose, the property DetachAllOnCommit is
not present in the source for PersistenceManager.java.  Further, should this
property also be on PersistenceManagerFactory that specifies the default
setting for any PMs obtained from the PMF, similar to other properties?
Attached is the updated PersistenceManager.java patch -- I have commit
priviledges, but I figured I'd send the patch for review before committing
it.  Please object soon if you're going to... :)

--matthew
-----Original Message-----
From: Craig Russell [mailto:Craig.Russell@Sun.COM] 
Sent: Tuesday, September 20, 2005 3:02 PM
To: jdo-dev@db.apache.org; JDO Expert Group
Subject: Detach test case names


Hi Matthew, 


Here are some test case names for review. This is from the spreadsheet. See
how well it comes out in email.


Craig


A12.6.8-1We define a new property called DetachOnClose
PersistenceManager.setDetachOnClose(boolean detachOnClose) sets the
DetachOnClose property

noapi/persistencemanager/detach/GetSetDetachOnClose
A12.6.8-2PersistenceManager.getDetachOnClose() gets the value for the
DetachOnClose property

noapi/persistencemanager/detach/GetSetDetachOnClose
A12.6.8-3With this flag set to true, after close, the PersistenceManager
guarantees that all persistent instances in the cache behave as detached
instances

noapi/persistencemanager/detach/DetachOnCloseCreatesDetachedInstances
A12.6.8-4can be serialized as detached instances.

noapi/persistencemanager/detach/SerializeCreatesDetachedInstances
A12.6.8-5restored serialized instances are treated as detached instances.

noapi/persistencemanager/detach/RestoreSerializedInstances
A12.6.8-9The order of instances in the parameter Collection's iteration
corresponds to the order of corresponding instances in the returned
Collection's iteration.

noapi/persistencemanager/detach/DetachOrderOfDetachedInstances
A12.6.8-10If a detachCopy method is called with an active transaction, the
parameter Collection of instances is first made persistent, and the
reachability algorithm is run on the instances

noapi/persistencemanager/detach/DetachReachabilityOfDetachedInstances
A12.6.8-11If a detachCopy method is called outside an active transaction,
the reachability algorithm will not be run; if any transient instances are
reachable via persistent fields, a JDOUserException is thrown for each
persistent instance containing such fields.

noapi/persistencemanager/detach/DetachTransientInstancesOutsideTransactionTh
rowsException
A12.6.8-12If a detachCopy method is called outside an active transaction,
the NontransactionalRead property must be true or JDOUserException is
thrown.

noapi/persistencemanager/detach/DetachOutsideTransactionRequiresNontransacti
onalRead
A12.6.8-13For each instance in the parameter Collection, a corresponding
detached copy is created.

noapi/persistencemanager/detach/DetachCreatesCopies
A12.6.8-14If there are duplicates in the parameter Collection, the
corresponding detached copy is used for each such duplicate.

noapi/persistencemanager/detach/DetachDuplicatesCreatesSingleInstance
A12.6.8-15Instances in the persistent-new and persistent-dirty state are
updated with their object identity and version

noapi/persistencemanager/detach/DetachNewAndDirtyInstancesAreUpdated
A12.6.8-16If instances in a deleted state (either persistent-deleted or
persistent-new-deleted) are attempted to be detached, a JDOUserException is
thrown with nested JDOUserExceptions, one for each such instance.

noapi/persistencemanager/detach/DetachDeletedInstancesThrowsException
A12.6.8-17All fields outside the FetchPlan in the detached instances are set
to the Java language default value for the type of the field.

noapi/persistencemanager/detach/DetachedUnloadedFieldsHaveDefaultValues
A12.6.8-18Fields in the FetchPlan of primitive and wrapper types are set to
their values from the datastore

noapi/persistencemanager/detach/DetachFieldsLoadedFromDatabase
A12.6.8-19Fields of references to persistence-capable types are set to the
detached copy corresponding to the persistent instance.

noapi/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances
A12.6.8-20Fields of Collections and Maps are set to detached SCO instances
containing references to detached copies corresponding to persistent
instances in the datastore.

noapi/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances
A12.6.8-21While detached, any field access to a field that was not fetched
throws JDODetachedFieldAccessException.

noapi/persistencemanager/detach/AccessingUnloadedFIeldsThrowsException
A12.6.8-22Each detached instance has a persistent identity that can be
obtained via the static JDOHelper method getObjectId(Object pc).

noapi/persistencemanager/detach/DetachedInstancesGetObjectId
A12.6.8-23The version of detached instances can be obtained by the static
JDOHelper method getVersion(Object pc).

noapi/persistencemanager/detach/DetachedInstancesGetObjectId
A12.6.8-24Each detached instance must be of a class identified in the JDO
metadata as detachable, or a JDOUserException is thrown with a nested
JDOUserException for each such instance.

noapi/persistencemanager/detach/DetachNonDetachableThrowsException
A12.6.8-25The order of instances in the parameter Collection's iteration
corresponds to the order of corresponding instances in the returned
Collection's iteration.

noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
A12.6.8-26Changes made to instances while detached are applied to the
corresponding persistent instances in the cache.

noapi/persistencemanager/detach/AttachAppliesChangesToPersistentInstances
A12.6.8-27New instances associated with the detached instances are added to
the persistent instances in the corresponding place.

noapi/persistencemanager/detach/AttachOrderOfDetachedInstances
A12.6.8-28If it cannot determine if changes were made, then it must mark the
instance dirty.

noapi/persistencemanager/detach/AttachMarksInstancesDirty
A12.6.8-29The makeTransactional flag, if set to true, requires the
implementation to mark transactional the persistent instances corresponding
to all instances in the closure of the detached graph.

noapi/persistencemanager/detach/AttachMarksInstancesTransactional
A12.6.8-30If an instance that is not of a detachable class is attempted to
be attached, a JDOUserException is thrown with a nested JDOUserException for
each such instance.

noapi/persistencemanager/detach/AttachNonDetachableThrowsException






Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

RE: Detach test case names

Posted by "Matthew T. Adams" <ma...@xcalia.com>.
Trying again with patch attachment...

-----Original Message-----
From: Matthew T. Adams [mailto:matthew.adams@xcalia.com] 
Sent: Wednesday, September 21, 2005 3:10 PM
To: jdo-dev@db.apache.org; 'JDO Expert Group'
Subject: RE: Detach test case names


As I'm currently working on the first assertion in this list (A12.6.8-1), it
looks like the spreadsheet text is outdated -- the property is
DetachAllOnCommit, not DetachOnClose.  I recall EG discussions on
DetachOnClose -- is that still on the table, or is it gone?
 
Regardless of the status of DetachOnClose, the property DetachAllOnCommit is
not present in the source for PersistenceManager.java.  Further, should this
property also be on PersistenceManagerFactory that specifies the default
setting for any PMs obtained from the PMF, similar to other properties?
Attached is the updated PersistenceManager.java patch -- I have commit
priviledges, but I figured I'd send the patch for review before committing
it.  Please object soon if you're going to... :)

--matthew

-----Original Message-----
From: Craig Russell [mailto:Craig.Russell@Sun.COM] 
Sent: Tuesday, September 20, 2005 3:02 PM
To: jdo-dev@db.apache.org; JDO Expert Group
Subject: Detach test case names


Hi Matthew, 

Here are some test case names for review. This is from the spreadsheet. See
how well it comes out in email.

Craig


A12.6.8-1
We define a new property called DetachOnClose
PersistenceManager.setDetachOnClose(boolean detachOnClose) sets the
DetachOnClose property




no
api/persistencemanager/detach/GetSetDetachOnClose

A12.6.8-2
PersistenceManager.getDetachOnClose() gets the value for the DetachOnClose
property




no
api/persistencemanager/detach/GetSetDetachOnClose

A12.6.8-3
With this flag set to true, after close, the PersistenceManager guarantees
that all persistent instances in the cache behave as detached instances




no
api/persistencemanager/detach/DetachOnCloseCreatesDetachedInstances

A12.6.8-4
can be serialized as detached instances.




no
api/persistencemanager/detach/SerializeCreatesDetachedInstances

A12.6.8-5
restored serialized instances are treated as detached instances.




no
api/persistencemanager/detach/RestoreSerializedInstances

A12.6.8-9
The order of instances in the parameter Collection's iteration corresponds
to the order of corresponding instances in the returned Collection's
iteration.




no
api/persistencemanager/detach/DetachOrderOfDetachedInstances

A12.6.8-10
If a detachCopy method is called with an active transaction, the parameter
Collection of instances is first made persistent, and the reachability
algorithm is run on the instances




no
api/persistencemanager/detach/DetachReachabilityOfDetachedInstances

A12.6.8-11
If a detachCopy method is called outside an active transaction, the
reachability algorithm will not be run; if any transient instances are
reachable via persistent fields, a JDOUserException is thrown for each
persistent instance containing such fields.




no
api/persistencemanager/detach/DetachTransientInstancesOutsideTransactionThro
wsException

A12.6.8-12
If a detachCopy method is called outside an active transaction, the
NontransactionalRead property must be true or JDOUserException is thrown.




no
api/persistencemanager/detach/DetachOutsideTransactionRequiresNontransaction
alRead

A12.6.8-13
For each instance in the parameter Collection, a corresponding detached copy
is created.




no
api/persistencemanager/detach/DetachCreatesCopies

A12.6.8-14
If there are duplicates in the parameter Collection, the corresponding
detached copy is used for each such duplicate.




no
api/persistencemanager/detach/DetachDuplicatesCreatesSingleInstance

A12.6.8-15
Instances in the persistent-new and persistent-dirty state are updated with
their object identity and version




no
api/persistencemanager/detach/DetachNewAndDirtyInstancesAreUpdated

A12.6.8-16
If instances in a deleted state (either persistent-deleted or
persistent-new-deleted) are attempted to be detached, a JDOUserException is
thrown with nested JDOUserExceptions, one for each such instance.




no
api/persistencemanager/detach/DetachDeletedInstancesThrowsException

A12.6.8-17
All fields outside the FetchPlan in the detached instances are set to the
Java language default value for the type of the field.




no
api/persistencemanager/detach/DetachedUnloadedFieldsHaveDefaultValues

A12.6.8-18
Fields in the FetchPlan of primitive and wrapper types are set to their
values from the datastore




no
api/persistencemanager/detach/DetachFieldsLoadedFromDatabase

A12.6.8-19
Fields of references to persistence-capable types are set to the detached
copy corresponding to the persistent instance.




no
api/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances

A12.6.8-20
Fields of Collections and Maps are set to detached SCO instances containing
references to detached copies corresponding to persistent instances in the
datastore.




no
api/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances

A12.6.8-21
While detached, any field access to a field that was not fetched throws
JDODetachedFieldAccessException.




no
api/persistencemanager/detach/AccessingUnloadedFIeldsThrowsException

A12.6.8-22
Each detached instance has a persistent identity that can be obtained via
the static JDOHelper method getObjectId(Object pc).




no
api/persistencemanager/detach/DetachedInstancesGetObjectId

A12.6.8-23
The version of detached instances can be obtained by the static JDOHelper
method getVersion(Object pc).




no
api/persistencemanager/detach/DetachedInstancesGetObjectId

A12.6.8-24
Each detached instance must be of a class identified in the JDO metadata as
detachable, or a JDOUserException is thrown with a nested JDOUserException
for each such instance.




no
api/persistencemanager/detach/DetachNonDetachableThrowsException

A12.6.8-25
The order of instances in the parameter Collection's iteration corresponds
to the order of corresponding instances in the returned Collection's
iteration.




no
api/persistencemanager/detach/AttachOrderOfDetachedInstances

A12.6.8-26
Changes made to instances while detached are applied to the corresponding
persistent instances in the cache.




no
api/persistencemanager/detach/AttachAppliesChangesToPersistentInstances

A12.6.8-27
New instances associated with the detached instances are added to the
persistent instances in the corresponding place.




no
api/persistencemanager/detach/AttachOrderOfDetachedInstances

A12.6.8-28
If it cannot determine if changes were made, then it must mark the instance
dirty.




no
api/persistencemanager/detach/AttachMarksInstancesDirty

A12.6.8-29
The makeTransactional flag, if set to true, requires the implementation to
mark transactional the persistent instances corresponding to all instances
in the closure of the detached graph.




no
api/persistencemanager/detach/AttachMarksInstancesTransactional

A12.6.8-30
If an instance that is not of a detachable class is attempted to be
attached, a JDOUserException is thrown with a nested JDOUserException for
each such instance.




no
api/persistencemanager/detach/AttachNonDetachableThrowsException





Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:Craig.Russell@sun.com

P.S. A good JDO? O, Gasp!

RE: Detach test case names

Posted by "Matthew T. Adams" <ma...@xcalia.com>.
As I'm currently working on the first assertion in this list (A12.6.8-1), it
looks like the spreadsheet text is outdated -- the property is
DetachAllOnCommit, not DetachOnClose.  I recall EG discussions on
DetachOnClose -- is that still on the table, or is it gone?
 
Regardless of the status of DetachOnClose, the property DetachAllOnCommit is
not present in the source for PersistenceManager.java.  Further, should this
property also be on PersistenceManagerFactory that specifies the default
setting for any PMs obtained from the PMF, similar to other properties?
Attached is the updated PersistenceManager.java patch -- I have commit
priviledges, but I figured I'd send the patch for review before committing
it.  Please object soon if you're going to... :)

--matthew

-----Original Message-----
From: Craig Russell [mailto:Craig.Russell@Sun.COM] 
Sent: Tuesday, September 20, 2005 3:02 PM
To: jdo-dev@db.apache.org; JDO Expert Group
Subject: Detach test case names


Hi Matthew, 

Here are some test case names for review. This is from the spreadsheet. See
how well it comes out in email.

Craig


A12.6.8-1
We define a new property called DetachOnClose
PersistenceManager.setDetachOnClose(boolean detachOnClose) sets the
DetachOnClose property




no
api/persistencemanager/detach/GetSetDetachOnClose

A12.6.8-2
PersistenceManager.getDetachOnClose() gets the value for the DetachOnClose
property




no
api/persistencemanager/detach/GetSetDetachOnClose

A12.6.8-3
With this flag set to true, after close, the PersistenceManager guarantees
that all persistent instances in the cache behave as detached instances




no
api/persistencemanager/detach/DetachOnCloseCreatesDetachedInstances

A12.6.8-4
can be serialized as detached instances.




no
api/persistencemanager/detach/SerializeCreatesDetachedInstances

A12.6.8-5
restored serialized instances are treated as detached instances.




no
api/persistencemanager/detach/RestoreSerializedInstances

A12.6.8-9
The order of instances in the parameter Collection's iteration corresponds
to the order of corresponding instances in the returned Collection's
iteration.




no
api/persistencemanager/detach/DetachOrderOfDetachedInstances

A12.6.8-10
If a detachCopy method is called with an active transaction, the parameter
Collection of instances is first made persistent, and the reachability
algorithm is run on the instances




no
api/persistencemanager/detach/DetachReachabilityOfDetachedInstances

A12.6.8-11
If a detachCopy method is called outside an active transaction, the
reachability algorithm will not be run; if any transient instances are
reachable via persistent fields, a JDOUserException is thrown for each
persistent instance containing such fields.




no
api/persistencemanager/detach/DetachTransientInstancesOutsideTransactionThro
wsException

A12.6.8-12
If a detachCopy method is called outside an active transaction, the
NontransactionalRead property must be true or JDOUserException is thrown.




no
api/persistencemanager/detach/DetachOutsideTransactionRequiresNontransaction
alRead

A12.6.8-13
For each instance in the parameter Collection, a corresponding detached copy
is created.




no
api/persistencemanager/detach/DetachCreatesCopies

A12.6.8-14
If there are duplicates in the parameter Collection, the corresponding
detached copy is used for each such duplicate.




no
api/persistencemanager/detach/DetachDuplicatesCreatesSingleInstance

A12.6.8-15
Instances in the persistent-new and persistent-dirty state are updated with
their object identity and version




no
api/persistencemanager/detach/DetachNewAndDirtyInstancesAreUpdated

A12.6.8-16
If instances in a deleted state (either persistent-deleted or
persistent-new-deleted) are attempted to be detached, a JDOUserException is
thrown with nested JDOUserExceptions, one for each such instance.




no
api/persistencemanager/detach/DetachDeletedInstancesThrowsException

A12.6.8-17
All fields outside the FetchPlan in the detached instances are set to the
Java language default value for the type of the field.




no
api/persistencemanager/detach/DetachedUnloadedFieldsHaveDefaultValues

A12.6.8-18
Fields in the FetchPlan of primitive and wrapper types are set to their
values from the datastore




no
api/persistencemanager/detach/DetachFieldsLoadedFromDatabase

A12.6.8-19
Fields of references to persistence-capable types are set to the detached
copy corresponding to the persistent instance.




no
api/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances

A12.6.8-20
Fields of Collections and Maps are set to detached SCO instances containing
references to detached copies corresponding to persistent instances in the
datastore.




no
api/persistencemanager/detach/DetachRelationshipsSetToDetachedInstances

A12.6.8-21
While detached, any field access to a field that was not fetched throws
JDODetachedFieldAccessException.




no
api/persistencemanager/detach/AccessingUnloadedFIeldsThrowsException

A12.6.8-22
Each detached instance has a persistent identity that can be obtained via
the static JDOHelper method getObjectId(Object pc).




no
api/persistencemanager/detach/DetachedInstancesGetObjectId

A12.6.8-23
The version of detached instances can be obtained by the static JDOHelper
method getVersion(Object pc).




no
api/persistencemanager/detach/DetachedInstancesGetObjectId

A12.6.8-24
Each detached instance must be of a class identified in the JDO metadata as
detachable, or a JDOUserException is thrown with a nested JDOUserException
for each such instance.




no
api/persistencemanager/detach/DetachNonDetachableThrowsException

A12.6.8-25
The order of instances in the parameter Collection's iteration corresponds
to the order of corresponding instances in the returned Collection's
iteration.




no
api/persistencemanager/detach/AttachOrderOfDetachedInstances

A12.6.8-26
Changes made to instances while detached are applied to the corresponding
persistent instances in the cache.




no
api/persistencemanager/detach/AttachAppliesChangesToPersistentInstances

A12.6.8-27
New instances associated with the detached instances are added to the
persistent instances in the corresponding place.




no
api/persistencemanager/detach/AttachOrderOfDetachedInstances

A12.6.8-28
If it cannot determine if changes were made, then it must mark the instance
dirty.




no
api/persistencemanager/detach/AttachMarksInstancesDirty

A12.6.8-29
The makeTransactional flag, if set to true, requires the implementation to
mark transactional the persistent instances corresponding to all instances
in the closure of the detached graph.




no
api/persistencemanager/detach/AttachMarksInstancesTransactional

A12.6.8-30
If an instance that is not of a detachable class is attempted to be
attached, a JDOUserException is thrown with a nested JDOUserException for
each such instance.




no
api/persistencemanager/detach/AttachNonDetachableThrowsException





Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/jdo

408 276-5638 mailto:Craig.Russell@sun.com

P.S. A good JDO? O, Gasp!