db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <Craig.Russ...@Sun.COM>
Subject Re: Detach test case names
Date Thu, 22 Sep 2005 01:59:58 GMT
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!


Mime
View raw message