You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Michael Bouschen <mb...@spree.de> on 2005/12/01 12:22:44 UTC
Re: [jira] Updated: (JDO-166) Implement new JDO 2 query tests cases
concerning deletion by query.
Hi Craig,
> 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.
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.
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
Re: [jira] Updated: (JDO-166) Implement new JDO 2 query tests cases
concerning deletion by query.
Posted by Craig L Russell <Cr...@Sun.COM>.
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!