Difference between revisions of "EclipseLink/Development/JPA2.0/access type"

From Eclipsepedia

Jump to: navigation, search
(General Solution)
(General Solution)
Line 18: Line 18:
  
 
# Determine the access type as we previously did taking into the consideration the entity @Access type mentioned above.
 
# Determine the access type as we previously did taking into the consideration the entity @Access type mentioned above.
** An XML access setting on an entity will override an @Access specification on that same entity or a mapped superclass.
+
## An XML access setting on an entity will override an @Access specification on that same entity or a mapped superclass.
 
## If no access is specified, the entity will then be determined by an entity-mappings access specification, followed by a default-metadata access specification, followed by the default to where annotations are defined on the class.
 
## If no access is specified, the entity will then be determined by an entity-mappings access specification, followed by a default-metadata access specification, followed by the default to where annotations are defined on the class.
 
# Process the accessors accordingly (and as we currently do)
 
# Process the accessors accordingly (and as we currently do)

Revision as of 16:45, 2 September 2008

Contents

Access Type

JPA 2.0 Root | Enhancement Request

Issue Summary

In JPA 2.0 the specification extends the access type configuration. Access Type will be specified at the Entity Level or the Property Level. New annotations have also been added providing configuration in the Java Class along with orm.xml

See JPA 2.0 ED section 2.1.2 for details.

General Solution

WIP

Our Entity Processing code must now process the entire entity as access type can be changed on a per property basis. The default and inheritance rules have not changed however and our current implementation can remain. The only exception to this rule is that inheritance subclasses can now explicitly specify the Access annotation and override the the inherited access type from (from the root. The root being the first parent that defines an inheritance strategy). So that will require a minor change to our current processing logic.

A quick break down of the processing would then look as follows:

Entity processing:

  1. Determine the access type as we previously did taking into the consideration the entity @Access type mentioned above.
    1. An XML access setting on an entity will override an @Access specification on that same entity or a mapped superclass.
    2. If no access is specified, the entity will then be determined by an entity-mappings access specification, followed by a default-metadata access specification, followed by the default to where annotations are defined on the class.
  2. Process the accessors accordingly (and as we currently do)
  3. New processing step, process the inverse access type accessors. That is,
    1. If the access type is FIELD, process those properties that explicitly define Access(PROPERTY), ignore all others.
    2. If the access type is PROPERTY, process those fields that explicitly define Access(FIELD), ignore all others.
  4. At all stages of processing an exception will be thrown in the following cases:
    1. An Access(FIELD) is found on a property
    2. An Access(PROPERTY) is found on a field.

Embeddable processing:

  1. Encountered during the entity processing and will continue to inherit it's access type from the owning entity. The exception case now being if the @Embeddable defines an access type.
  2. Processing of the embedable accessors will follow the processing logic defined for an entity.

Other notes:

  1. XML merging (an EclipseLink internal functionality) remains as implemented. No changes are necessary.

Work Required

  1. Develop model for testing access type settings
    approx 2 days
  2. Update Processing to process entire table
    approx 3 days