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/MetadataCollection

Metadata Collection Requirements and Design 

Enhancement Request: bug 330846

This feature will help eclipselink users to gather the metadata configurations annotated on/in several different entities on to a single centralized location (class)  for better maintenence over time. The prposed feature will leverage existing standards and convensions for grouping metadata and builds upon the same to further simplify its usage and maintenence. 


List of Requirements:

   This feature should provide eclipselink users the ability to group:

  • all types of related named queries
  • all related resultset mappings
  • all related converters
  • all related query redirectors   

at a central place like any ordinary utility class

Metadata

The following sections will give in detail the changes and modifications that are required for implementing this feature.

The Metadata Collection is somewhat similar to the existing support for assembling all metatadata in eclipselink-orm.xml; however, it does not aim to be an all encompassing storehouse for the entire metadata of the project, as is the eclipselink-orm.xml. It is expected to be used to group related metadata for easier maintenance.

This  feature will be available in both the Java annotations and XML mappings.

Annotation:

  @MetadataCollection
/* 
A Metadata Collection can be defined on any ordinary java class to group related metadata like 
named queries, resultset mappings, convertors, query redirectors, etc at a central place rather than 
on an entity to increase reusability and clarity of code. A central location will also simplify the 
maintenance of these metadata. A eclipselink persistence project can have several classes that have been 
marked with Metadata Collection so that the users can group related metadata in to several sets for easier 
maintenance.

*/
 
@Target(TYPE) 
@Retention(RUNTIME) 
public @interface MetadataCollection{ 
    NamedQueries namedQueries(); 
    NamedNativeQueries namedNativeQueries();  
    NamedStoredProcedureQueries namedStoredProcedureQueries();  
    SQLResultSetMappings[] resultSetMappings() default {}; 
    Convertors convertors(); 
    QueryRedirectors queryRedirectors;
}

XML Element

A metadata complex xml element will be created to group all related metadata together:


<xs:complexType name="metadata-collection"> 

     <xs:annotation> 

        <xs:documentation> 

        </xs:documentation>  

     </xs:annotation> 

     <xs:sequence> 

         <xs:element name="named-queries"  minOccurs="0">
              <xs:element ref="named-query"/> 
         </xs:element> 

         <xs:element name="named-native-queries" minOccurs="0"> 
              <xs:element ref="named-native-query"/>
         </xs:element> 

         <xs:element name="named-stored-procedure-queries"> 
              <xs:element ref="named-stored-procedure-query"/> 
         </xs:element> 

         <xs:element name="resultset-mappings" minOccurs="0"> 
              <xs:element ref="sql-resultset-mapping"/>
         </xs:element> 

        <xs:element name="convertors" minOccurs="0" 
              <xs:element ref="convertor"/> 
         </xs:element> 

      <xs:element name="query-redirectors" minOccurs="0"> 
              <xs:element ref="query-redirector"/>
         </xs:element> 

    </xs:sequence> 

</xs:complexType> 


Example:

@MetadataCollection{
     namedQueries={
          @NamedQuery(name=SavingsAccountQueries.fetchWithdrawalBalance, query="SELECT account.balance 
                      FROM Account account WHERE account.user=:userName"),

     },
     namedStoredProcedureQueries={
     },
     convertors={
          @Convertor(name=SavingsAccountQueries.genderConvertor,
                convertorClass=com.company.product.module.convertors.GenderConvertor)
      
     }

}

public class SavingsAccountQueries {

    public static final String fetchWithdrawalBalance="fetchWithdrawalBalance";
    public static final String genderConvertor="genderConvertor";

} 

<metadata-collection><named-queries> <named-query name="fetchWithdrawalBalance" query="SELECT account.balance FROM Account account WHERE account.userName=:userName"/> 
</named-query> 
<named-native-queries> 
<named-native-query name="" query=""/> 
</named-native-queries> 
<named-stored-procedure-queries> 
<named-stored-procedure-query name="" query="" /> 
</named-stored-procedure-queries> 
<result-set-mappings> 
<sql-resultset-mapping> 
   <!-- <entity>and <field> mappings --> 
</sql-resultset-mapping> 
</resultset-mappings> 
<convertors> 
<convertor name="" class=""> 
</convertor> 
</convertors> 
<query-redirectors> 
<query-redirector allqueries="DefaultRedirector.class"/> 
</query-redirectors> 

</metadata-collection>

The above named query can be executed in the normal way as shown below:

Query query=entityManager.createNamedQuery(SavingsAccountQueries.fetchWithdrawalBalance);
query.setParameter("userName",userName);
Double balance=(Double)query.getSingleResult();

Metadata Overriding and Merging

The order of precedence for the metadata grouped using this feature will be resolved in the following order descendingly:

  1. eclipselink-orm.xml
  2. orm.xml
  3. @MetadataCollection Annotation
  4. Inhertance of metadata from super class that has been annotated with @MetadataCollection
  5. Individual container annotations for the respective metadata on entity or MappedSuperClass classes

Internal Mapping

Since this annotation is just aggregating several pieces of metadata, and does not have any identity of its own, we do not need to store any mapping for this metadata object, unless we want to provide isolation for metadata defined between two different metadata collections.

Core

This feature does not require any changes in the public facing API of the eclipselink core; however, it does need an important change in the way eclipselink scans for metadata.

Presently only classes that have @Entity or @Embeddale or @MappedSuperClass are searched for resolving JPA metadata; but this feature proposes a facility to group metadata on any ordinary class and hence we need to also search for classes that has @MetadataCollection annoation.

Also, the metadata objects of type MetadataCollection need to be resolved before any of the contained metadata ( like NamedQueryMetada, SQLResultSetMappingMetadata, etc) is processed so that the contained metadata within each metadata collection can be processed along with similar metadata that has been annotated on enitites and embeddables

Exceptions/Open Issues/Future

  • We need to compile the details about which metadata can be centrally defined and which is tightly localised to an entity
  • Can we let any other annotations be defined on non-entity classes?

 

Back to the top