Oracle TopLink

Oracle TopLink 11g (11.1.1.0.0)

September 2008


Oracle TopLink 11gR1

Oracle TopLink 11gR1 released in July 2009 is the latest in the 11g family. Please refer to the TopLink 11gR1 Feature Overview for details.

Introduction

Oracle TopLink 11g (11.1.1.0.0) offers a significant set of new features and marks its first release based on the open-source EclipseLink project. EclipseLink is derived from a previous version of Oracle TopLink, which Oracle contributed to the Eclipse Foundation in 2006.

This document describes the Oracle TopLink features in 11g in the following areas:

Object-Relational Persistence

TopLink 11g includes support for the native TopLink ORM API as well as the Java Persistence API (JPA) through EclipseLink. This section briefly describes the important new features including:

Java Persistence API (JPA) Support

The Java Persistence API (JPA), part of the Java Enterprise Edition 5 (Java EE 5) Enterprise Java Beans (EJB) 3.0 specification, greatly simplifies Java persistence and provides an object-relational mapping approach that allows you to declaratively define how to map Java objects to relational database tables in a standard, portable way that works both inside a Java EE 5 application server and outside an EJB container in a Java Standard Edition (Java SE) 5 application.

In 11g, TopLink includes EclipseLink which is fully compliant with the JPA 1.0 specification. You can use EclipseLink as your JPA persistence provider in Java SE and EE applications.

JPA Extensions

In TopLink 11g, EclipseLink provides a rich set of extensions for advanced JPA usage. You can access EclipseLink extended JPA functionality using custom annotations, persistence unit properties, query hints, and EclipseLink custom API.

Use EclipseLink JPA extensions for:

Mappings

11g provide annotations to configure advanced mapping including:

  • @BasicCollection - stores a collection of simple types, such as String, Number, Date, etc., in a single table

  • @BasicMap - stores a collection of key-value pairs of simple types, such as String, Number, Date, etc., in a single table

  • @PrivateOwned - supports orphan management

  • @JoinFetch - enables the joining and reading of a referenced object(s) in the same query as the source object

  • @Mutable - indicates that the value of a complex field itself can be changed or not changed (instead of being replaced)

  • @Transformation - enables the mapping of a single field to to one or more database columns.

  • @VariableOneToOne - supports OneToOne mappings to an interface rather than an Entity

  • @ReadOnly - makes an Entity read only

Mapping Customization

Use the @Customizer EclipseLink annotation to register a class that can customize the mappings for an Entity using the EclipseLink native API.

@Entity
@Customizer(EmployeeCustomizer.class)
public class Employee implements Serializable {...


public class EmployeeCustomizer implements DescriptorCustomizer {
    public void customize(ClassDescriptor Descriptor) throws Exception {

You can also use a number of customization persistence unit properties to override some customization annotation attributes and to configure other customization options not supported by annotations.

Converters

11g provides a number of new converter features including ease of configuration using JPA annotations. EclipseLink JPA converter annotations include: @Converter, @TypeConverter, @ObjectTypeConverter, @StructConverter, and @Convert. With these annotations it's easy to perform data type conversion and work with user defined types.

In the following example, a converter named Currency is defined and associated with the custom converter class CurrencyConverter. The CurrencyConverter class is responsible for converting between a database string representation of a currency (e.g., USD) and the corresponding java.util.Currency object. Annotating the Employee's salaryCurrency field with @Convert("Currency") ensures that the conversion between Currency object and database String is automatically performed when reading, writing, or updating an Employee object.

@Entity
...
@Converter(name="Currency", converterClass=CurrencyConverter.class)
public class Employee implements Serializable {
       
    ...
    @Convert("Currency")
    private Currency salaryCurrency;

Entity Caching

11g introduces new JPA annotations for configuring Entity caching and (@Cache , @TimeOfDay) and existence checking policy (@ExistenceChecking). In the following example, the Employee Entity is configured with a HardWeak cache and an expiry policy that will invalidate all instances at 1am. Time of day expiry is useful in systems with regular datafeeds. Other expiry options are supported by the @Cache annotation. With the CHECK_DATABASE expiry policy specified, the database will be checked to see if a new object to be persisted already exists on the database.

@Entity
@Cache(type=CacheType.HARD_WEAK, expiryTimeOfDay=@TimeOfDay(hour=1))
@ExistenceChecking(ExistenceType.CHECK_DATABASE)
public class Employee implements Serializable {

A number of caching persistence unit properties are also available to override some entity caching annotations, define defaults, and to configure caching options not supported by annotations.

Optimistic Locking

The new @OptimisticLocking annotation supports the configuration of advanced optimistic locking policies that are especially useful when dealing with legacy database schemas that may not have a version or timestamp column. In the following example, the Employee Entity is configured with a CHANGED_COLUMNS optimistic locking policy. This policy will generate an UPDATE SQL statement that ensures that all columns being modified still have the same value as when they were read.

@Entity
@OptimisticLocking(type=OptimisticLockingType.CHANGED_COLUMNS)
public class Employee implements Serializable {
Query Hints

In 11g, an extensive set of query hints are available to leverage many advance query features including batch and join reading, cache usage options, pessimistic locking, and many more. When using a hint, you can set the value using the public static final field in the appropriate configuration class in the org.eclipse.persistence.config package, including PessimisticLock, QueryHints, and HintValues.

Stored Procedure Query

Stored procedure usage has been simplified through the @NamedStoredProcedureQuery and @NamedStoredProcedureQueries annotations. These annotations support the use of stored procedures which are encapsulated as named queries so that they are easy to use. Client code is unaware that the query they are executing is a stored procedure and not a JPQL or native SQL query

Lazy Loading

If you are developing your application in a Java EE environment, you only have to set the fetch attribute of any JPA mapping to FetchType.LAZY (unless it defaults to FetchType.LAZY). EclipseLink JPA will supply all the necessary lazy loading functionality.

If you are developing your application in a Java SE environment you can enable lazy loading support for all mapping types by configuring either dynamic or static weaving.

Schema Generation

Generation of the database schema for the Entities in a persistence unit is configured through persistence unit properties. Supported options include whether to generate the schema on the database, to file, or both, what directory to generate a files into, and whether to drop and create tables or just create.

Returning Policy

11g includes the new @ReturnInsert and @ReturnUpdate annotations for configuring returning policy options. Returning policies enable INSERT or UPDATE operations to return values back into the object being written. These values include table default values, trigger or stored procedures computed values that may modify data that is inserted or updated. On the Oracle Database, specifying an @ReturnInsert or @ReturnUpdate will add a RETURNING clause to insert and update statements to efficiently reread modified data. On databases other than Oracle, the underlying ReturningPolicy can be configured using a descriptor customizer.

In the following example, whenever an Employee Entity is inserted or updated its firstName and lastName fields will be updated with the value from the database:

@Entity
public class Employee implements Serializable {
    ...
    @ReturnInsert
    @ReturnUpdate
    private String firstName;
    @ReturnInsert
    @ReturnUpdate
    private String lastName;

Change Tracking

Use the @ChangeTracking annotation to configure the way changes to Entities are computed. Change calculation can be deferred until a transaction is committed or can be tracked as the object is modified.

JPA Configuration

11g offers significant configuration and customization in the following areas:

  • JDBC - persistence unit properties enable the configuration of parameter binding, statement caching, batch writing and more.

  • Logging - persistence unit properties enable the configuration of logging level, details (e.g., thread, session, etc.), output target and other options.

  • Database, Application Server and Session - persistence unit properties are provided to specify the target database and application server to enable platform specific integration and features (e.g., Oracle Database native sequencing). Configuration options are also available to enable usage of Native ORM projects through the JPA API instead of through a Session.

Performance Enhancements

In 11g, JPA performance has been enhanced with features including:

  • Change tracking for JPA entities

  • Read-only queries

  • Parameter binding: now enabled by default.

  • Joining: additional support for many-to-many, direct-collection, direct-map, and aggregate-collection mappings, and mapping level inner and outer join support

  • Inheritance: support for outer joining inheritance subclasses on queries, and support for joining classes with inheritance

  • Improved performance and concurrency

  • Dynamic Expression and JPQL parse cache

Oracle Spatial Support

11g includes the new org.eclipse.persistence.platform.database.oracle.converters.JGeometry converter to provide support for working with Oracle Spatial data and querying.

For more information on Oracle Spatial, see http://www.oracle.com/technology/products/spatial/index.html.

Stored Procedure Configuration in ORM Project.xml

In 11g, the project.xml XSD supports stored procedure configuration. This allows improved stored procedure configuration support in tools like Oracle JDeveloper.

Object-XML Binding

The new Object-XML Binding functionality in TopLink 11g is provided by the EclipseLink MOXy (Mapping Objects to XML) component. In 11g, MOXy supports the following new features:

  • Support for JAXB 2.0 API

  • JAXB 2.0 Schema and Object Model Generation

SDO: Service Data Objects

In TopLink 11g, EclipseLink supports Service Data Objects (SDO) for Java specification version 2.1. SDO provides a standardized programmer API for the creation and manipulation of data objects that can be exchanged between applications in a platform and programming language neutral XML format. Service Data Objects provide an object API for working with XML documents in Java. They can be marshalled to and from XML that conform to a specified XML schema (XSD). Changes to SDOs are reflected in XML when they are marshaled and may be captured in a Change Summary. SDO leverages EclipseLink MOXy to provide a high performance SDO implementation for use in Service Component Architecture (SCA), Java SE, and Java EE applications.

SDO 2.1 provides the ability to:

  • Generate Java SDO classes (static SDOs) from an XML Schema.

    Static SDOs implement getters and setters that follow the JavaBean convention.

  • Generate SDO Types and Properties at runtime from an XML Schema to create dynamic SDOs.

    These objects do not follow the JavaBean convention. Instead they provide generic methods to get and set properties of an SDO.

  • Generate an XML schema that corresponds to the types and properties of an SDO model.

    This allows XML payloads in, for example, web services to include the schema that they conform to making the payload contents fully self describing.

  • Capture and marshal to XML the set of changes made to an SDO object graph in an SDO Change Summary.

    Using change summaries reduces the amount of data the needs to be transmitted between collaborating SDO applications.

 


Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065

Worldwide Inquiries:
+1.650.506.7000
Fax +1.650.506.7200
oracle.com

Copyright 2008. All Rights Reserved.
This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, PeopleSoft, and Retek are registered trademarks of
Oracle Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.

E-mail this page
Printer View Printer View
Oracle Is The Information Company About Oracle | Oracle RSS Feeds | Careers | Contact Us | Site Maps | Legal Notices | Terms of Use | Privacy