Hi David and Matthew,
Thanks for the response. Regarding the design issues, I agree that it is a Java problem. In jdo this problem becomes more evident. If I want to delete an object in java, I need to set all references to null. In JDO I need to set all references to null and actually delete the object. I noticed that a lot of beginners with JDO assume that when deleting the objects the other part, setting references to null, is done automatically, which is not the case. In any case it is something which needs to be dealt with and it is now left to the developer to do it. What I do now is that for each object I determine which objects are referencing it. This usually comes down to executing queries where I check whether a certain attribute is or contains the object. I figured with all the available jdo meta data this could be something that can be done by the framework? Moreover, this code easily breaks on refactoring. That would also be nicely solved if the jdo metadata is used. Regarding the performance, I am not sure what makes this solution slower than the current solution, doing it yourself, that is, if my assumption that it can be done with the jdo metadata is correct. Collecting the metadata is probably a fraction of the actual time to delete the object in the datastore. So the performance decrease will be caused by querying attributes which could possibly contain the object according to the metadata, but which you as a developer know is not the case. I would say if performance becomes a problem in that case you can always go back by doing it yourself, or provide some extra metdata to getAllReferencingObjects so these classes can be skipped. This is also the approach I have currently. I first use my generic delete algorithm to recursively determine what needs to be deleted and what references need to be updated. If I notice or know this will be slow due to a large collection of objects I will switch to a delete-by-query and optimize the number of objects that need to be updated. But again, it is hardly ever considered slow due to the getAllReferencingObjects(), but more due to the actual deleting of large collections of objects using pm.deletePersistentAll(). Kind regards, Christiaan
