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

From Eclipsepedia

Jump to: navigation, search
(New page: = Access Type = JPA 2.0 Root | [http://bugs.eclipse.org/241651 Enhancement Request] ==Issue Summary== In JPA 2.0 the specification extends the acces...)
 
m (General Solution)
 
(15 intermediate revisions by one user not shown)
Line 5: Line 5:
 
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
 
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.
+
See JPA 2.0 ED section 2.3 for details.
  
 
==General Solution==
 
==General Solution==
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.
 
  
 +
Our Entity Processing code must now process the entire entity if an explicit access type has been specified. Also since 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) this will now need to be changed to the first parent of the inheritance hierarchy that does not specify an explicit type. We therefore need to change our processing to ensure inheritance hierarchies are completely processed top->down. Previously we only ensured the root of the inheritance hierarchy had been processed before processing a sub-class of that hierarchy.
 +
 +
A quick break down of the processing logic to determine the access type is as follows:
 +
 +
===Entity access type:===
 +
 +
# Check for an explicit access type setting in XML on the entity
 +
# Check for an explicit access type setting on the entity class
 +
# Check the parents access type of an inheritance hierarchy (ignoring those parents with an explicit access type)
 +
## Note: Inheritance hierarchies are processed top down
 +
# Check the location of annotations on the mapped superclasses (ignoring those mapped superclasses with an explicit access type)
 +
# Check the location of annotations on the entity class itself
 +
# Check for an xml default from a persistence-unit-metadata-defaults or entity-mappings setting.
 +
# Search has been exhausted, EclipseLink will default to FIELD.
 +
 +
===Embeddable access type:===
 +
 +
# Check for an explicit access type setting in XML on the embeddable
 +
# Check for an explicit access type setting on the embeddable class
 +
# Inherits the default access type from the owning entity (as defined from steps 3-7 in Entity access type above).
 +
 +
===Mapped superclass access:===
 +
 +
# Check for an explicit access type setting in XML on the embeddable
 +
# Check for an explicit access type setting on the embeddable class
 +
# Inherits the default access type from the owning entity (as defined from steps 3-7 in Entity access type above).
 +
 +
===Id class access:===
 +
# Inherits the default access type from the owning entity (as defined from steps 3-7 in Entity access type above).
 +
 +
Processing of class accessors (entity, embeddable, mapped superclasses) is the as follows:
 +
 +
# Process the accessors accordingly (and as we currently do)
 +
# New processing step, process the inverse access type accessors if an explicit access type has been specified.
 +
## If the access type is FIELD, process those properties that explicitly define Access(PROPERTY), ignore all others.
 +
## If the access type is PROPERTY, process those fields that explicitly define Access(FIELD), ignore all others.
 +
# At all stages of processing an exception will be thrown in the following cases:
 +
## An Access(FIELD) is found on a property
 +
## An Access(PROPERTY) is found on a field.
 +
 +
===Other notes:===
 +
 +
# XML merging (EclipseLink extended functionality) remains as implemented. No changes are necessary.
  
 
==Work Required==
 
==Work Required==
Line 15: Line 57:
 
#: approx 2 days
 
#: approx 2 days
 
# Update Processing to process entire table
 
# Update Processing to process entire table
#: approx 3 days
+
#: approx 5 days

Latest revision as of 13:42, 28 October 2008

Contents

[edit] Access Type

JPA 2.0 Root | Enhancement Request

[edit] 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.3 for details.

[edit] General Solution

Our Entity Processing code must now process the entire entity if an explicit access type has been specified. Also since 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) this will now need to be changed to the first parent of the inheritance hierarchy that does not specify an explicit type. We therefore need to change our processing to ensure inheritance hierarchies are completely processed top->down. Previously we only ensured the root of the inheritance hierarchy had been processed before processing a sub-class of that hierarchy.

A quick break down of the processing logic to determine the access type is as follows:

[edit] Entity access type:

  1. Check for an explicit access type setting in XML on the entity
  2. Check for an explicit access type setting on the entity class
  3. Check the parents access type of an inheritance hierarchy (ignoring those parents with an explicit access type)
    1. Note: Inheritance hierarchies are processed top down
  4. Check the location of annotations on the mapped superclasses (ignoring those mapped superclasses with an explicit access type)
  5. Check the location of annotations on the entity class itself
  6. Check for an xml default from a persistence-unit-metadata-defaults or entity-mappings setting.
  7. Search has been exhausted, EclipseLink will default to FIELD.

[edit] Embeddable access type:

  1. Check for an explicit access type setting in XML on the embeddable
  2. Check for an explicit access type setting on the embeddable class
  3. Inherits the default access type from the owning entity (as defined from steps 3-7 in Entity access type above).

[edit] Mapped superclass access:

  1. Check for an explicit access type setting in XML on the embeddable
  2. Check for an explicit access type setting on the embeddable class
  3. Inherits the default access type from the owning entity (as defined from steps 3-7 in Entity access type above).

[edit] Id class access:

  1. Inherits the default access type from the owning entity (as defined from steps 3-7 in Entity access type above).

Processing of class accessors (entity, embeddable, mapped superclasses) is the as follows:

  1. Process the accessors accordingly (and as we currently do)
  2. New processing step, process the inverse access type accessors if an explicit access type has been specified.
    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.
  3. 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.

[edit] Other notes:

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

[edit] Work Required

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