|
Marc Prud'hommeaux made changes - 30/Aug/06 01:17 AM
Michael Bouschen made changes - 10/Sep/06 06:58 PM
Michael Bouschen made changes - 10/Sep/06 07:41 PM
Looks good.
I think your analysis is correct, and using Insurance as the candidate class solves the relationship management issues. Checked in the patch (see revision 443483).
Michael Bouschen made changes - 14/Sep/06 09:34 PM
Merged changes from trunk into brach 2.0.1 (see revision 452644).
Michael Bouschen made changes - 03/Oct/06 09:55 PM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The whole point in adding the delete API to the Query interface is to support instance removal without the need to load these instances before the removal. I think using class Person to test the delete API is not a good idea. As Marc pointed out, it requires nulling relationship fields prior to the removal and this means loading instances into memory. So it might happen that the instances to be deleted are loaded prior to removal which is not the intent of the test case.
I propose to change the test case and use a class where the database schema does not include any foreign keys referencing the table for the class. In the company model class Insurance is an example for such a class. The attached patch for review implements this proposal.