Talk:EclipseLink/Development/JPA2.0/uni-directional onetomany mapping

Discussion

Versioning

I don't understand how versioning will work, do you intend to check or update the version? Won't this conflict with the target object's versioning causing lock exceptions when the object changes? Why would the target object version be incremented, doesn't the source own the relationship entirely? Does the JPA spec say anything about the version locking requirements? Perhaps versioning should be similar to m-m and only update the source version, if and only if the source is using cascaded locking.

13:26, 12 August 2008 (EDT)

Removed target versioning from the doc.

History

You mentioned history support, how is this going to work exactly? Seems like the mapping would require its' own history policy similar to m-m?

James.sutherland.oracle.com 13:26, 12 August 2008 (EDT)

That was the idea. History support should be provided only if all other mappings support it. However if there are mappings that don't support history (AggregateCollectionMapping?) history support for UnidirectionalOneToManyMapping could be skipped.

Queries

The design on how insert, update, delete, remove are going to be handled are missing. How are each of these going to be implemented? Does delete of the source if private owned do a batch delete-all, or just delete each target object? What about not private owned? What custom queries will this mapping support? Will batch reading and joining work correctly given the target objects do not have the foreign key mapped? How will the batched objects be matched up with the source? Will query additionalFields be used?

James.sutherland.oracle.com 13:26, 12 August 2008 (EDT)

Added queries description tp the doc. Start working on joining, will work on batch reading later.

Id

What is the foreign key is part of the target object's primary key? Does the JPA spec allow this? If the user defines a read-only basic for the foreign key will this work?

James.sutherland.oracle.com 13:26, 12 August 2008 (EDT)

Foreign key being part of target's primary key will NOT be supported. The problem is that target object deemed to be independent: suppose we are to create new source and target objects - both objects registered in uow, then both independently inserted - which of course causes NPE on attempt to insert the target. The only way to avoid that is NOT to insert the target independently, but use the source and its UnidirectionalOneToManyMapping instead - exactly what AggregateCollectionMapping does. This use case should be handled by ElementCollection in JPA 2.0.

If user maps target's foreign key with writable mapping we should throw exception.

API

The new public API should be listed in the doc (new class name, custom query API).

James.sutherland.oracle.com 11:31, 13 August 2008 (EDT)