db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michelle Caisse <Michelle.Cai...@Sun.COM>
Subject Re: Detach test case names
Date Thu, 22 Sep 2005 18:26:30 GMT
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 
>> <mailto: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 
>>> <mailto:matthew.adams@xcalia.com>>
>>> ]
>>> Sent: Wednesday, September 21, 2005 3:18 PM
>>> To: jdo-dev@db.apache.org <mailto: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 
>>> <mailto:matthew.adams@xcalia.com>>
>>> ]
>>> Sent: Wednesday, September 21, 2005 3:10 PM
>>> To: jdo-dev@db.apache.org <mailto: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 <mailto:Craig.Russell@Sun.COM>>]
>>> Sent: Tuesday, September 20, 2005 3:02 PM
>>> To: jdo-dev@db.apache.org <mailto: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 
>>> <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 <Craig.Russell@sun.com 
>>> <mailto:Craig.Russell@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!
>
>


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