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.
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!
