Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EclipseLink/Development/JPA2.0/Extended Map support/MappedKeyMapContainerPolicy

CollectionTableMapMapping will be any Map mapping that contains either part of it's key or part of its value in a CollectionTable. Much of CollectionTableMapMapping's functionality will be similar to ManyToManyMapping because of the fact that both mappings use a relation table.

Goals

  • Provide a mapping that will satisfy the JPA 2.0 specification requirements for Maps. This feature specifically addresses maps that store some of their information in a collection table.
  • Support basic EclipseLink CRUD and additional features like batch reading and join fetches
  • As a second step, implement the JPA 2.0 metadata including Annotations and XML configuration
  • Implement core-level testing for the basic feature
  • Implement jpa-level testing for JPA 2.0 parts of the functionality

High Level Design

Mapping Hierarchy

The mapping hierarchy will be updated to include new abstract class CollectionTableMapping with two subclasses, ManyToManyMapping and CollectionTableMapMapping.

CollectionTableMapping

CollectionTableMapping will contain a large portion of the code that is now contained in ManyToManyMapping. It will be responsible for everything on the source side of the relationship:

  • It will hold the insert, update and delete queries for the mapping
  • It will contain the keys for source side of the relationship
  • It will provide the framework that allows its subclasses to work

ManyToManyMapping

ManyToManyMapping will now inherit from RelationTableMapping, and now contain the information and functionality to cope with the target part of the relationship.

  • It will contain the target keys
  • It will initialize the queries stored in its parent class
  • It will manage the target side of the relationship

CollectionTableMapMapping

The new CollectionTableMapMapping class will be added as a subclass of RelationTableMapping. It will store the mappings for the key and the value of the map.

  • It will a mapping related to the key and one related to the value of the map
  • It will initialize the mappings it holds and the queries stored in its superclass
  • It will provide the functionality needed to deal with multiple mappings for the target
  • It will delegate much of the functionality related to its keys and values to its contained mappings

MapComponentMapping

A new interface will be created call MapComponentMapping. This interface will provide the API that mapping that can be either the key or the value for a CollectionTableMapMapping must implement. The following mappings will implement this interface:

  • AbstractDirectMapping
  • AggregateObjectMapping
  • OneToOneMapping

Only MapComponentMappings will be eligible as the key or value of a CollectionTableMapMapping. It will abstract the following funtionality:

  • Adding required fields to selectionQuery, insertQuery, deleteQuery for the owning mapping
  • Extracting results of queries and using them to build the target
  • Cloning the target
  • Initiailization

Container Policy Hierarchy

A new subclass of MapContainerPolicy will be added called CollectionTableMapContainerPolicy.

CollectionTableMapContainerPolicy

CollectionTableMapContainerPolicy is a new subclass of MapContainerPolicy that allows map components to be derived from mappings instead of from objects.

  • Contains a reference to its owning mapping key mapping and value mapping
  • Overrides parent funtionality to allow the key mapping and value mapping to be considered when adding to a map

Iteration

ContainerPolicy provides an abstraction that allows you to iterate through the collection the ContainerPolicy represents. This abstraction will be extended. With the addition of CollectionTableMapMapping, it is necessary to iterate over collections that may contain a key-value pair rather than a single value. The iterator abstraction will have support added that allows iteration through collections that contain key-value pairs. The functionality will be kept as transparent as possible, users of this iterator abstraction will all have to be updated to consider the fact that the values they iterate through could potentially be a key value pair.

Open Issues

  • Which advanced features must be supported?
    • History Policy
  • JPQL updates are planned as a separate enhancement

Back to the top