RelationshipManager caters for subset of relation changes and should be extended to add other possibilities

[andyjefferson]

For example, with RDBMS there is an amount of logic in FKSetStore, FKListStore, JoinSetStore, JoinListStore to manage some relation changes. This code should be moved to RelationshipManager so then all datastores would benefit from the relation management code. SVN trunk now caters for set of a Collection field (replace the collection by a different collection, detecting the add/remove of elements).

JDO spec 15.3 for reference purposes.

The field on the other side of the relationship can be mapped by using the mapped-by attribute identifying the field on the side that defines the mapping. Regardless of which side changes the relationship, flush (whether done as part of commit or explicitly by the user) will modify the datastore to reflect the change and will update the memory model for consistency. There is no further behavior implied by having both sides of the relationship map to the same database column(s). In particular, making a change to one side of the relationship does not imply any runtime behavior by the JDO implementation to change the other side of the relationship in memory prior to flush, and there is no requirement to load fields affected by the change if they are not already loaded. This implies that if the RetainValues flag or DetachAllOnCommit is set to true, and the relationship field is loaded, then the implementation will change the field on the other side so it is visible after transaction completion.

Similarly, if one side is deleted, the other side will be updated to be consistent at flush. During flush, each relationship in which the instance is involved is updated for consistency. These changes are applied to the object model instances. If the relationship is marked as dependent, the related instance is deleted. If the relationship is not marked as dependent, the corresponding field in the related instance is updated to not refer to the instance being deleted: • If the related field is a collection, then any referencing element is removed. • If the related field is a map, then any referencing map entry is removed. • If the related field is a reference, then it is set to null. If the related instances are not instantiated in memory, there is no requirement to instantiate them. Changes are applied to the second level cache upon commit.

The object model changes are synchronized to the database according to the declared mapping of the relationships to the database. If related instances are to be deleted, and there is a foreign key declared with a delete action of cascade delete, then the jdo implementation need do nothing to cause the delete of the related instance. Similarly, if there is a foreign key declared with a delete action of nullify, then the jdo implementation need do nothing to cause the column of the mapped relationship to be set to null. If there is a foreign key declared to be not nullable, and the requirement is to nullify the related field, then JDODataStoreException is thrown at flush.

Conflicting changes to relationships cause a JDOUserException to be thrown at flush time. Conflicting changes include: • adding a related instance with a single-valued mapped-by relationship field to more than one one-to-many collection relationship • setting both sides of a one-to-one relationship such that they do not refer to each other