Module org.eclipse.persistence.jpa
Package org.eclipse.persistence.internal.jpa.metadata.accessors.classes

Class EmbeddableAccessor

java.lang.Object
org.eclipse.persistence.internal.jpa.metadata.ORMetadata
org.eclipse.persistence.internal.jpa.metadata.accessors.MetadataAccessor
org.eclipse.persistence.internal.jpa.metadata.accessors.classes.ClassAccessor
org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EmbeddableAccessor
public class EmbeddableAccessor extends ClassAccessor
INTERNAL: An embeddable accessor. Key notes: - any metadata mapped from XML to this class must be compared in the equals method. - any metadata mapped from XML to this class must be handled in the merge method. (merging is done at the accessor/mapping level) - any metadata mapped from XML to this class must be initialized in the initXMLObject method. - methods should be preserved in alphabetical order.
Since:
EclipseLink 1.0

  • Constructor Details

  • Method Details

    • addEmbeddingAccessor

      protected void addEmbeddingAccessor(ClassAccessor embeddingAccessor)
      INTERNAL: Embedding accessors are those accessors that actually embed the embeddable class with an embedded mapping. We use this list to extract and validate the access type of this embeddable when the embeddable does not specify an explicit access type.

    • addEmbeddingAccessors

      public void addEmbeddingAccessors(Map<String,ClassAccessor> embeddingAccessors)
      INTERNAL:

    • addOwningDescriptor

      public void addOwningDescriptor(MetadataDescriptor owningDescriptor)
      INTERNAL:

    • addOwningDescriptors

      public void addOwningDescriptors(List<MetadataDescriptor> owningDescriptors)
      INTERNAL:

    • addPotentialEmbeddableAccessor

      protected void addPotentialEmbeddableAccessor(MetadataClass potentialEmbeddableClass, ClassAccessor embeddingAccessor)
      INTERNAL Ensure any embeddable classes that are discovered during pre-process are added to the project. The newly discovered embeddable accesors will also be pre-processed now as well.
      Overrides:
      addPotentialEmbeddableAccessor in class ClassAccessor
      See Also:

    • discoverMappedSuperclassesAndInheritanceParents

      protected void discoverMappedSuperclassesAndInheritanceParents(boolean addMappedSuperclassAccessors)
      INTERNAL: Build a list of classes that are decorated with a MappedSuperclass annotation or that are tagged as a mapped-superclass in an XML document. This method will also do a couple other things as well since we are traversing the parent classes: - Build a map of generic types specified and will be used to resolve actual class types for mappings. - save mapped-superclass descriptors on the project for later use by the Metamodel API We don't support embeddable inheritance yet. When that is added, this method will need to change and in fact we may be able to re-use the existing discover method from EntityAccessor (with minor tweaks).

    • getEmbeddingAccessors

      public Map<String,ClassAccessor> getEmbeddingAccessors()
      INTERNAL:

    • getOwningDescriptor

      public MetadataDescriptor getOwningDescriptor()
      INTERNAL: So, here's the deal ... this method typically gets called when defaulting pk's name, primary table names etc. for various mappings. The problem however is that we go beyond the spec and allow more mappings to be specified on embeddable classes. For example, a M-M would default its join table and join columns using the info from its owning descriptor. The problem then is ... what to do when this embedabble has multiple owning descriptors? That is, is shared. Right now, their pk names from the owners better be same or mappings must be fully specified and not use any defaults. I think that is somewhat ok given we're going beyond the spec and TopLink doesn't even support it anyway??? So the stance is, we'll allow the extra mappings on embeddables that are not shared, however on shared cases there are restrictions. Users should use mapped superclasses when they have a need to share complex embeddables. Or they can write customizers to modify their embeddable descriptors after initialize (after they have been cloned) Future: the metadata processing 'could' set all necessary (per owning descriptor) metadata and have the descriptor initialize code handle it. Metadata processing would process embeddable classes as it currently does for MappedSuperclasses. Clone them and process under each owning entity context. At descriptor initialize time, we would avoid cloning the aggregate descriptor and use the one metadata processing provided. Investigate further at a later date ... Callers to this method are ... BasicCollectionAccessor - processCollectionTable - defaults pk names from the owning descriptor. RelationshipAccessor - processJoinTable - defaults the join table name and the source field name OneToManyAccessor - processUnidirectionalOneToManyMapping - defaults the pk field and table. MappingAccessor - processAssociationOverride and updatePrimaryKeyField. ObjectAccessor - processId
      Overrides:
      getOwningDescriptor in class ClassAccessor
      See Also:

    • isEmbeddableAccessor

      public boolean isEmbeddableAccessor()
      INTERNAL: Return true if this accessor represents an embeddable accessor.
      Overrides:
      isEmbeddableAccessor in class ClassAccessor

    • preProcess

      public void preProcess()
      INTERNAL: The pre-process method is called during regular deployment and metadata processing. This method is called after each entity of the persistence unit has had an opportunity to pre-process itself first since we'll rely on owning entities for things like access type etc. The pre-process will run some validation. The order of processing is important, care must be taken if changes must be made.
      Overrides:
      preProcess in class ClassAccessor

    • preProcessForCanonicalModel

      public void preProcessForCanonicalModel()
      INTERNAL: The pre-process for canonical model method is called (and only called) during the canonical model generation. The use of this pre-process allows us to remove some items from the regular pre-process that do not apply to the canonical model generation. The order of processing is important, care must be taken if changes must be made.
      Overrides:
      preProcessForCanonicalModel in class ClassAccessor

    • preProcessMappedSuperclassMetadata

      protected void preProcessMappedSuperclassMetadata(MappedSuperclassAccessor mappedSuperclass)
      INTERNAL Sub classes (Entity and Embeddable) must override this method to control the metadata that is processed for their context.
      Overrides:
      preProcessMappedSuperclassMetadata in class ClassAccessor
      See Also:

    • process

      public void process()
      INTERNAL: Process the metadata from this embeddable class.
      Overrides:
      process in class ClassAccessor

    • processAccessMethods

      public void processAccessMethods()
      INTERNAL: For VIRTUAL access we need to look for default access methods that we need to use with our mapping attributes.

    • processAccessType

      protected void processAccessType()
      INTERNAL: Process the access type of this embeddable. If this embeddable is not embedded by at least one entity, it will not be processed. Therefore, embedding accessors can not be empty at this point.
      Specified by:
      processAccessType in class ClassAccessor

    • processMappedSuperclassMetadata

      protected void processMappedSuperclassMetadata(MappedSuperclassAccessor mappedSuperclass)
      INTERNAL From an embeddable we need pair down what we process as things like ID metadata does not apply.
      Overrides:
      processMappedSuperclassMetadata in class ClassAccessor
      See Also: