Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Thu, 01 Dec 2005 08:41:06 -0800
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: [jira] Updated: (JDO-166) Implement new JDO 2 query tests cases
 concerning deletion by query.
In-reply-to: <438EDD04.5020306@spree.de>
Sender: Craig.Russell@Sun.COM
To: jdo-dev@db.apache.org
Message-id: <21BA81BB-AF8C-4523-B5B1-4C500F97A341@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_s/PcPL+EIPCRWj6zLK1+5g)"
References: <1888552249.1133183318129.JavaMail.jira@ajax.apache.org>
 <CDB0705D-A633-49F1-9C65-0FE1570594B5@sun.com> <438C2728.3060504@spree.de>
 <F549E2CE-89F6-4961-9588-6EA357F3C937@sun.com> <438EDD04.5020306@spree.de>

--Boundary_(ID_s/PcPL+EIPCRWj6zLK1+5g)
Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII
Content-transfer-encoding: 7BIT

Hi Michael,

On Dec 1, 2005, at 3:22 AM, Michael Bouschen wrote:

> Hi Craig,
>
>> Hi Michael,
>> On Nov 29, 2005, at 2:02 AM, Michael Watzek wrote:
>>> Hi Craig,
>>>
>>>> Hi Michael,
>>>> 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.
>
> I think the comment was misleading and caused the confusion.  
> Actually, Michael added three different test queries: one with a  
> result clause, another one with a result class and this one one  
> having both. I think all we need to do is clean up the comment,  
> because all the necessary test scenarios are covered.
>
As I recall it, at the time I reviewed the test case it had only one  
test query containing both a result and result class. That is the one  
I suggested to split into two test queries.

So it sounds like we're all agreed.

Craig

> Regards Michael
>
>
>> Regards,
>> Craig
>>>
>>> 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!
>
>
> -- 
> Michael Bouschen		Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de	http://www.tech.spree.de/
> Tel.:++49/30/235 520-33		Buelowstr. 66			
> Fax.:++49/30/2175 2012		D-10783 Berlin			

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!


--Boundary_(ID_s/PcPL+EIPCRWj6zLK1+5g)--