|
|
 |
 |
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:
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:
-
-
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
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:
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. |
|
|
|
|