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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
-------------------------------------------------------------------
Michael Watzek [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
--
Michael Bouschen [EMAIL PROTECTED] Engineering GmbH
mailto:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
