Hi Craig,
"We actually have changed the specification in this regard, so that if you are using a mapping in which a single database artifact (e.g. primary key, foreign key) is used to describe two or more concepts, the deletion of an instance causes the cleanup of other instances that refer to that deleted instance." Can you tell me where this is described in the spec? Are you referring to the mapped-by attribute in JDO2 to deal with updating of references or the delete/update action for foreign keys? For the latter, the jdo implementation I am using has the following comment on this: <null: If the referenced row is deleted or changes its primary key, null the columns of this foreign key. Some databases do not support this action.> Unfortunately, the database I am using doesn't support this. "Do all of your examples use delete as the cause of the issue?" Most of them, but it could also be handy to maintain integrity when updating one-one relationships and one-to-many. Btw, with jdo1 the recommendation was to manually maintain all references, which is fine by me, since you have that to do that in plain java as well. I just thought that getAllReferencingObjects() could be a handy method in doing this and would not only save the developer time in writing this code himself it would also be less maintenance sensitive. "Would it be better to describe the delete semantics instead of having the user worry about it?" Not sure what you mean with this. Who is the user in this case? As I see it there is no user worrying about this, just the person who is designing/implementing the persistent objects. With the available solutions he either has to maintain the update semantics in the metadata or he has to maintain his own implementation of getAllReferencingObjects()? Regards, Christiaan
