db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karan Malhi <karan.ma...@gmail.com>
Subject Re: Detach test case names
Date Thu, 22 Sep 2005 11:46:07 GMT
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> 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>
> ]
> 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<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 <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 <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 <Craig.Russell@sun.com>
>
> P.S. A good JDO? O, Gasp!
>
>
>


--
Karan Malhi

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message