[ http://issues.apache.org/jira/browse/JDO-166?page=comments#action_12358510 ]
Michael Bouschen commented on JDO-166: -------------------------------------- A few comments about JDO-166.patch: DeleteCallback: - There is a type in the javadoc of method queryUpdateDeleteVerify: hoplder. The javadoc says: "... makes dirty all queried pc instances calling ...". I would say: "marks all queried pc instances as dirty by calling ... ". - Method verifyCallbacksAndStates lists the oids of the deleted instances in an error message. Maybe it should say that the values are oids and not pc instances. DeleteQueryElements - I like the idea of describing why a query listed in INVALID_QUERIES is not valid for delete by query. Maybe you can add this for all the queries: Invalid for delete by query, because ... - The valid query is a unique query, but the expected number of deleted instances is 3! > 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 > > 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
