db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: [jira] Updated: (JDO-166) Implement new JDO 2 query tests cases concerning deletion by query.
Date Wed, 30 Nov 2005 21:41:48 GMT
Hi Michael,

On Nov 29, 2005, at 2:02 AM, Michael Watzek wrote:

> Hi Craig,
>> Hi Michael,
>> Test class DeleteQueryElements has INVALID_QUERIES for which the   
>> comments are incorrect. They should all start with "The query is   
>> invalid because...". I suspect that you copied some of these from   
>> other query tests, but there are more requirements for delete.
>> For example, I suggest changing "The query may fail because there  
>> is  a grouping clause, or because there is a grouping clause w/o  
>> result"  to "The query is invalid because there is a grouping  
>> clause".
> Ok.
>> I'd also suggest making two test cases from the test case"The  
>> query  may fail because there is a result, or  because there is a  
>> result  class". These sound like different cases.
> I assume, you mean two different test methods, rather than two  
> different test classes?

Different cases == different situations, not different "test classes".
> Up to now, all JDO2 query test classes implementing negative test  
> cases execute those within the same method (testNegative()). For  
> example, test class DeleteQueryElements executes the following test  
> cases within testNegative():
> 1) invalid result clause,
> 2) invalid result class,
> 3) invalid grouping,
> 4) invalid ordering,
> 5) invalid range.
> Is your suggestion to split up 1) - 5) into different negative test  
> methods?

No, it's simply to make two queries instead of one. There's nothing  
wrong with your strategy.

If I read the negative queries correctly, you have a delete query  
with both result class and result.

So, my suggestion is to split out the query into two so that one  
invalid query has a result class and another invalid query has a result.


> If yes, I propose to make a separate issue out of it because this  
> affects more classes than just DeleteQueryElements. There are  
> several JDO2 query test classes executing more than one test case  
> within testNegative().
> Regards,
> Michael
>> I notice in QueryTest that the execute method always starts a   
>> transaction. Are there any tests that query outside a transaction?
>> Thanks,
>> Craig
>> On Nov 28, 2005, at 5:08 AM, Michael Watzek (JIRA) wrote:
>>>      [ http://issues.apache.org/jira/browse/JDO-166?page=all ]
>>> Michael Watzek updated JDO-166:
>>> -------------------------------
>>>     Attachment: JDO-166.patch2
>>> The second patch implements the comments above.
>>>> Implement new JDO 2 query tests cases concerning deletion by query.
>>>> -------------------------------------------------------------------
>>>>          Key: JDO-166
>>>>          URL: http://issues.apache.org/jira/browse/JDO-166
>>>>      Project: JDO
>>>>         Type: New Feature
>>>>   Components: tck20
>>>>     Reporter: Michael Watzek
>>>>     Assignee: Michael Watzek
>>>>  Attachments: JDO-166.patch, JDO-166.patch2
>>>> We need 4 new test classes, one for each of the following  
>>>> assertions:
>>>> - A14.8-1: These methods delete the instances of affected  
>>>> classes  that pass the filter, and all dependent instances.  
>>>> Affected  classes are the candidate class and its persistence- 
>>>> capable  subclasses.
>>>> - A14.8-2: The number of instances of affected classes that  
>>>> were  deleted is returned. Embedded instances and dependent  
>>>> instances  are not counted in the return value.
>>>> - A14.8-3: Query elements filter, parameters, imports,  
>>>> variables,  and unique are valid in queries used for delete.  
>>>> Elements result,  result class, range, grouping, and ordering  
>>>> are invalid. If any of  these elements is set to its non-default  
>>>> value when one of the  deletePersistentAll methods is called, a  
>>>> JDOUserException is  thrown and no instances are deleted.
>>>> - A14.8-4: Dirty instances of affected classes are first  
>>>> flushed  to the datastore. Instances already in the cache when  
>>>> deleted via  these methods or brought into the cache as a result  
>>>> of these  methods undergo the life cycle transitions as if  
>>>> deletePersistent  had been called on them. That is, if an  
>>>> affected class implements  the DeleteCallback interface, the  
>>>> instances to be deleted are  instantiated in memory and the  
>>>> jdoPreDelete method is called prior  to deleting the instance in  
>>>> the datastore. If any  LifecycleListener instances are  
>>>> registered with affected classes,  these listeners are called  
>>>> for each deleted instance. Before  returning control to the  
>>>> application, instances of affected  classes in the cache are  
>>>> refreshed by the implementation so their  status in the cache  
>>>> reflects whether they were deleted from the  datastore.
>>>> Details can be found on Wiki page http://wiki.apache.org/jdo/  
>>>> QueryTests#DeletionByQuery.
>>> -- 
>>> This message is automatically generated by JIRA.
>>> -
>>> If you think it was sent incorrectly contact one of the   
>>> administrators:
>>>    http://issues.apache.org/jira/secure/Administrators.jspa
>>> -
>>> For more information on JIRA, see:
>>>    http://www.atlassian.com/software/jira
>> 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!
> -- 
> -------------------------------------------------------------------
> Michael Watzek                  Tech@Spree Engineering GmbH
> mailto:mwa.tech@spree.de        Buelowstr. 66
> Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
> Fax.:  ++49/30/217 520 12       http://www.spree.de/
> -------------------------------------------------------------------

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!

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