Subscribe: Java Persistence
Added By: Feedage Forager Feedage Grade B rated
Language: English
custom  eclipselink  emp  java  jpa  new  oracle  persistence unit  persistence  project  release  spatial  support  toplink 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Java Persistence

Java Persistence

A blog dedicated to Java Persistence issues and solutions related to EclipseLink and Oracle TopLink.

Updated: 2016-07-10T11:00:39.035-04:00


EclipseLink 2.4:


EclipseLink 2.4.0 Juno - RELEASEDAs part of the Juno Eclipse release train the EclipseLink project has released EclipseLink 2.4.0. The release landing page describes some of the new and noteworthy features as well as providing links to documentation and examples so you can get started. What I would like to do is provide some colour commentary on the features new in this release. JSON BindingEclipseLink’s MOXy component has offered a JAXB compliant implementation for many years now.  It not only supports the standard JAXB features but also goes well beyond the standard to offer powerful advanced features, including XPath mappings, and support for defining mappings in XML instead of just annotations. In EclipseLink 2.4.0, MOXy has expanded its scope to support mapping Java objects to JSON. This support covers all of the MOXy mappings available in annotations, XML, and now JSON.  MOXy’s JSON support is enabled simply by setting the desired media-type on a marshaller or unmarshaller.  This support is unique as it marshalls/unmarshalls objects directly to and from JSON without any intermediate conversions.  And EclipseLink MOXy’s integration with EclipseLink JPA, originally written for XML mapping, makes serializing JPA entities to and from JSON easy.Learn more about EclipseLink MOXy's JSON ... HTML5/MobileDuring the development of 2.4 the team introduced JSON binding and we started building sample applications illustrating how this functionality could be leveraged with JAX-RS to simplify development. This lead us to discussions with the Jersey team as to how EclipseLink could better integrated. I parallel we continue to look at different client technologies to see what we can do in the persistence layer to simplify development. The convergence of these efforts is EclipseLink's JPA-RS feature which provides RESTful access to persistence units with either XML or JSON data formats.What I find most interesting about JPA-RS is what it offers to developers looking to access data for Thin Server Architecture (TSA) clients. In many cases client developers just need data in a consumable (and of course efficient and secure) format and having to build a full Java EE application to expose this data can be a barrier to entry. What we have done with JPA-RS is simplified how new applications can be developed with a JAX-RS+JPA back-end with minimal server side development.Learn more about JPA-RS... Cloud Enabled PersistenceStarting in EclipseLink 2.3 the EclipseLink team started exposing features to simplify development of applications that will be deployed in a cloud infrastructure or need to work in PaaS or SaaS scenarios. The solutions introduced included:@Multitenant(SINGLE_TABLE) allowing tables to store data from multiple tenants leveraging row level filtering.Extensible entities using virtual attributes so that the entity types can be customized post deployment to manage additional state. MetadataSource allows overriding mapping metadata (JPA and MOXy) to be retrieved dynamically during deployment or on refresh request. This allows persistence unit customization post development so that applications can be customizable at runtime as well as supporting deployment architectures where tenant specific extensions are enabled.In EclipseLink 2.4 we have further extended this support to include some additional tenant isolation options. @Multitenant(TABLE_PER_TENANT) allows different tables in the same schema to be used per tenant or dedicated schemas per tenant.MetadataSource has been extended to allow persistence unit properties, including data source information, to be dynamically provided at startup and refresh. This allows PaaS deployed application instances to retrieve isolated data source information per tenant.Learn more about EclipseLink's Tenant Isolation features ... NoSQLEclipseLink, even befor[...]

Czech Republic visit and EclipseLink Indigo (2.3)


Last week when I was in Prague I had the oppurtunity to catch up with Alexis-Moussine Pouchkine (@alexismp). While there Alexis recorded an interview with me about EclipseLink and we both spoke at the Java Developer Conference in Brno.
The developer conference was my first opportunity to present a talk on the work we have been doing within the EclipseLink project to address development of applications for the cloud. More specifically we have been busy working on some features which I think will be very interesting to all Java EE developers using JPA. These include:
  • @Multitenant: Support for configuring entities which have data from different tenants stored in the same table. EclipseLink will automatically apply additional criteria on all queries to only read and modify the rows for your current tenant.
  • Extensible Entities with Virtual Attributes (@VirtualAccessMethods): Allow for attributes to be mapped to database flex columns on the fly. This includes both JPA and JAXB mappings/bindings as well as tenant specific extensions.
  • MetadataSource: Allow for your XML specified JPA mappings or JAXB bindings to be dynamically loaded and used by your application from an external source. This allows you to customize your application on-the-fly from an external source.
In my presentation I did a demo of my new MySports demo application which I am busy wrapping up and documenting for the Eclipse Indigo release (June 22). This application shows off the new features with a multitenant JSF application which includes dynamic JSF rendering of extended attributes using the JPA 2.0 metamodel. The tenant configuration and provisioning is done using an admin application which uses REST and EclipseLink MOXy's binding support.

It should be a busy month wrapping up all of the necessary documentation and examples for the Indigo release so that EclipseLink

Oracle @ EclipseCon


Although it does not look like I will make it to Santa Clara this year for EclipseCon the rest of the team here at Oracle has put together an impressive set of sessions. If you are planning on attending EclipseCon here is a summary of the Oracle related sessions.

Using JPA 2.0 in WebLogic 10.3.4


Starting with the Oracle WebLogic 10.3.4 release it is now possible to upgrade to using JPA 2.0. The release includes TopLink (with EclipseLink 2.1.2).

Since WebLogic 10.3.4 is a compliant Java EE 5 implementation it is required to ship out of the box with support for EJB 3.0 and thus JPA 1.0. If you wish to upgrade your install to allow JPA 2.0 use you must follow install a small patch, which is documented here.

If you are making use of Oracle Enterprise Pack for Eclipse the new includes support for using the JPA 2.0 capabilities.


EclipseLink Filters How-To


I have been assisting customers with their comparison of JPA/Object-relational frameworks as well as assisting them with migrating to EclipseLink JPA. One issue I ran into recently involves migrating users of Hibernate who use Filters over to EclipseLink. A filter is basically an additional set of criteria with session specific arguments that are applied to all queries of a given entity type.EclipseLink has long supported additional criteria being configured on a descriptor (mapping for an entity type). In this blog I just wanted to post some simple example code that illustrates how additional criteria can be applied to a an entity type with parameters that are then specified in the creation of the EntityManager where the criteria is to be applied.Using either an annotation on the entity class as:@Entity@Customizer(AddEmployeeGenderCriteria.class)public class EmployeeAlternatively this customizer can be configured in persistence unit properties as well as in the eclipselink-orm.xml mapping file.This allows for a provided customer to be called and the descriptor for the entity type, Employee in this case, to be customized. Here we'll add the additional criteria (filter) that will later be used.public static class AddEmployeeGenderCriteria implements DescriptorCustomizer {public void customize(ClassDescriptor descriptor) throws Exception {ExpressionBuilder eb = new ExpressionBuilder(descriptor.getJavaClass());Expression genderExp = eb.get("gender").equal(new SessionPropertyValue("gender"));descriptor.getQueryManager().setAdditionalJoinExpression(genderExp);}}Note: The SessionPropertyValue class is an extension and is only required if the criteria has a parameter value that will be supplied dynamically per EntityManager.Now with the descriptor has been customized with the additional criteria for all Employee queries we simply need to provide the argument value when creating the"gender", "M");EntityManager em = emf.createEntityManager(properties);This will cause all queries such as:em.createQuery("SELECT e FROM Employee e WHERE e.firstName LIKE 'J%'", Employee.class).getResultList();To have the addtitional criteria added and the SQL generated appears as:SELECT t0.EMP_ID, t1.EMP_ID, t0.L_NAME, t0.END_TIME, t0.VERSION, t0.START_TIME, t0.GENDER, t1.SALARY, t0.F_NAME, t0.MANAGER_ID, t0.ADDR_ID, t0.START_DATE, t0.END_DATE FROM EMPLOYEE t0, SALARY t1 WHERE (t0.F_NAME LIKE ? AND ((t1.EMP_ID = t0.EMP_ID) AND (t0.GENDER = ?)))bind => [J%, M]The only additional requirement is that the entity types with the EntityManager specific 'filters' be only cached in the EntityManager (isolated/txn cache) instead of the default shared cache to ensure that filtered collections from one context are not incorrectly presented in another where different parameter values are used.The use of these types of filters is not all that common in my experience so improving the configuration has not been a priority. If you use these filters and would like to have the usage of them in EclipseLink improved we are eager to get your feedback.[...]

Off to Epicenter in Dublin


I am once again off to Dublin this week to speak at the Epicenter 2010 Conference again. Although I do enjoy a good Guiness I am also looking forward to the conference and the topics I am covering this week as well as the hours of travel to catch up on some pre-release tasks. We are just wrapping up our 2.1 release of EclipseLink as part of the Eclipse Helios release train and there are many new features I am excited about so travelling this week will give me a chance to complete some examples for the release and blog about the features all EclipseLink users will want to learn about.

I am speaking this week on performance and scalability. Even after 13 years of helping customers use TopLink and now EclipseLink I still find diagnosing, solving, and innovating in these areas some of the most interesting work I take part in. Helping customers learn what they need to know about their models and application use cases and translating them into their object-relational mappings, schema, and usage of their persistence layer is challenging and often poorly understand by Java developers.

The persistence layer enables performance and scalability but there are many simple decisions developers can make while configuring and coding to their persistence layer which are made early in projects and have big effects late in projects when trying to reach their performance and scalability goals. Understanding what these decisions are and what the trade-offs are is so important and hopefully I'll help some of our Irish community avoid common pitfalls.

After working with a couple clients this week dealing with tough performance goals and very complex models I have some great examples I'll be adding to my cook book of slides on my way over the Atlantic.

Hope to see you in Dublin...

EclipseLink on LinkedIn


I was back in the field last week helping a customer with their migration to EclipseLink from a 3rd party developed solution using TopLink Essentials. Generally these migrations are very straight forward but in this case we bumped into a few unique wrinkles caused by the original solution being developed on a very early version of our JPA 1.0 solution and the consultants building it introducing a partial JPA container that changed the default behaviour.

Ultimately we got the issues resolved in relatively short order and enjoyed a great meal with some of the consultants on the project in Halifax. I truly enjoy any chance I get to down into an application and help developers solve their persistence challenges.

During my visit I made some notes on a couple of take-aways.

1. Update the EclipseLink wiki's best practices to include a couple of additional scenarios around long-running transactions.

2. Help connect the existing community of Java professionals using EclipseLink.

I have already started on the first and will post some highlights here when the work is completed. To address the second action item I created the EclipseLink Group on LinkedIn.

The goal of this group is to allow any and all Java professionals who use LinkedIn to connect and share ideas, job opportunities, news, and upcoming events. If this sounds interesting to you please join the group and share your ideas.


Oracle Enterprise Pack for Eclipse 11g released at EclipseCon 2009


Enjoying another fun and informative week at EclipseCon.

The OEPE 11g release announced today includes excellent ORM tooling based on Dali as well as specific support for EclipseLink. Check out Pieter Humphrey's Blog entry for all the details.


My Thoughts on EclipseLink 1.0


We released EclipseLink 1.0. You can read about it on the EclipseLink Team Blog. Please do download it and try it out.Its been an interesting year since we first announced the contribution of Oracle TopLink to open source and the creation of the EclipseLink project. Taking a large product and all of its testing and moving it to a new repository with new build and test servers was technically challenging. Probably the more interesting changes however have been in how we developed 1.0 and the future releases of the project. Learning the Eclipse 'way' (project reviews, code contributions and the IP process, detailed road maps and public updates, web site, portal, wiki, bugzilla, ...) has been fun and interesting while only occasionally painful. Transitioning a large development team to this new open process was well worth the effort. We are now a community of committers that expands beyond just Oracle.This 1.0 release is really based on several years of development. This past year within the EclipseLink project plus all of the functionality developed in Oracle TopLink since our 10.1.3 release (February 2006) is included. While we tend to focus on the efforts of the past year many Oracle TopLink customers will find a significant amount of new features in the classic ORM/OXM support in addition to all the great new JPA/JAXB/SDO support. Over the next few weeks I will try to post blogs highlighting many of these features and how they can be used.There are a few high level items about this release I would like to point out:Minimal Dependencies: We ship with an eclipselink.jar library for JavaSE/EE users that can be used easily with minimal additional libraries. JPA users in JavaSE will just need to include the JPA 1.0 library (included as /jlib/jpa/persistence_1.0.0.jar) and their favourite JDBC driver. Within a JavaEE5 container you will just need the EclipseLink library as JPA should already be available as well as your JDBC drivers within the container's Data Source. Minimal dependencies is very important as it simplifies usage and avoids conflicts with other frameworks and your container's use of common libraries.Full Functionality: No matter how many times I say this I still get questions after my talks and webinars. All of the persistence functionality of Oracle TopLink is included in EclipseLink. All of the TopLink development team now exclusively develops new functionality in EclipseLink. We have also done a fair bit of work to enable the usage of our many advanced features through JPA. This includes custom annotations as well as XML configuration. Our goal is to keep developers as close to standard JPA as possible and simplify usage when you do need EclipseLink JPA's advanced features. OSGi Support: While I still personally feel like a newbie in the OSGi space I am very proud of how our developers have managed to address class-loader flexibility so that we can bundle our EclipseLink components for use in OSGi. The optional Equinox functionality to enable Dynamic/Load-Time weaving allows developers using Equinox (typically RCP) to build full featured JPA applications without fighting the persistence implementation. We have an example available if you want to try it out. Flexible Object Binding: The MOXy component does support JAXB2's annotations and XML schema compiler but what I think is most interesting is the ability to externalize the XML binding information. EclipseLink MOXy has its own XML mapping file as well as supporting mappings defined in code (statically or dynamically). Using this externalized mapping support with the standard JAXB marshal/unmarshal API is very powerful and allows a domain model to be easily persisted to multiple data sources/formats.Performance and Scalability: One aspect of Oracle TopLink development is that while we continued to evolve the produc[...]



Its been a big week for graduations. Earlier this week my son completed his time in kindergarden and today the EclipseLink project graduated from incubation status. Tonight I took a few minutes to finally remove the big egg from the EclipseLink home page.

As for my son, he is pretty focussed on spending every waking hour swimming until September. As for EclipseLink we are about ready to ship our 1.0 release on July 9th. In both cases it should be a fun and exciting summer.

We have been getting great feedback so far on EclipseLink and I would like to invite the entire Java community to download EclipseLink and try it out. We are eager to get your feedback and continue to expand the usage of our project.


EclipseLink in the News


Pretty exciting day so far at EclipseCon. We have been involved in two press releases at the conference so far.

Eclipse Announces EclipseLink Project to Deliver JPA 2.0 Reference Implementation

Eclipse Announces New Runtime Initiative around Equinox

Ian Skerrett
discusses this announcement and its implications. This announcement has a couple effects to the EclipseLink project. First off it provides a new top level project for us. We will move from the Technology project to the newly created Runtime project in the near future. This also formalizes our relationship with Equinox. We will soon be checking in our work to enabled EclipseLink's effective use in an OSGi environment.
Now that we have these announcements out I am looking forward to spending more time talking to other attendees about their work and how EclipseLink may be of use in their projects and applications.


Testing EclipseLink JPA applications in JavaSE


I spend part of my work days writing examples and helping users debug issues. I spend the majority of this time using JPA with our TopLink and now EclipseLink's advanced features.

One little piece of code I always find myself looking for is a way to take a JPA persistence unit configuration and use it in JavaSE without changing it. The idea is that my persistence unit which should run in the container should also be testable easily outside.

In the past I posted some examples of using XML to accomplish this but the following is the Java code that I use in my JavaSE examples and unit tests without going down the road of a separate persistence unit definition in XML for both worlds.

import static org.eclipse.persistence.jpa.config.PersistenceUnitProperties.*;


Map properties = new HashMap();

// Ensure RESOURCE_LOCAL transactions is used.

// Configure the internal EclipseLink connection pool
properties.put(JDBC_DRIVER, "oracle.jdbc.OracleDriver");
properties.put(JDBC_URL, "jdbc:oracle:thin:@localhost:1521:ORCL");
properties.put(JDBC_USER, "user-name");
properties.put(JDBC_PASSWORD, "password");
properties.put(JDBC_READ_CONNECTIONS_MIN, "1");
properties.put(JDBC_WRITE_CONNECTIONS_MIN, "1");

// Configure logging. FINE ensures all SQL is shown
properties.put(LOGGING_LEVEL, "FINE");

// Ensure that no server-platform is configured
properties.put(TARGET_SERVER, TargetServer.None);

I can then create my EntityManagerFactory using:

Persistence.createEntityManagerFactory("unit-name", properties);

The only remaining struggle I have is specifying which classes are my entities. The simplest way is to explicitly reference them in the persistence.xml or an associated orm.xml file. If they are listed explicitly then I do not need to worry about the automatic discovery.

EclipseLink does support automatic discovery of entity classes in JavaSE but you need to enable its usage using:


Hopefully having these snippets of code and XML handy will help some of you out and now I can easily find them wherever I am working.


Java Search Engine Integration for EclipseLink JPA


The creator and primary contributor to Compass has taken the initiative to provide support for using EclipseLink ( with Compass. I hope to find the time to build an application that illustrates the use of the two projects but thought I would post some early information to the community about the integration.

See the documentation

is described as:

Compass is a first class open source Java Search Engine Framework, enabling the power of Search Engine semantics to your application stack decoratively. Built on top of the amazing Lucene Search Engine, Compass integrates seamlessly to popular development frameworks like Hibernate, [and now EclipseLink] and Spring. It provides search capability to your application data model and synchronizes changes with the datasource. With Compass: write less code, find data quicker.

For those of you interested in adding richer search capabilities to your JPA applications you can now combine the capabilities of Lucenewith EclipseLink JPA through the Compass integration.



EclipseLink 1.0 Milestone 1: Now Available


We just made our first milestone build available for download. See the EclipseLink team blog for more information.

This is an important step for our project. Our plan is to produce monthly milestone builds as we work toward our 1.0 release. It does seem very odd to be starting back at a 1.0 release after over 10 years of shipping this Java persistence solution. For those familiar with TopLink this milestone is the complete capabilities from the Oracle TopLink 11gR1 Technology Preview 2. Since we were near completion of our development cycle for this release the new features available are complete and well tested.

We are also in the process of publishing the complete documentation from Oracle TopLink as the EclipseLink user manuals. This will be done on the wiki. This in conjunction with the evolving set of examples should help developers easily evaluate the use of this project.

Any and all feedback is appreciated. There is a newsgroup and users mailing list where feedback can be provided.

All information on the EclipseLink project can be found linked from our home page.



Its alive...


I am just heading out on vacation this morning and wanted to update the community on our progress in the Eclipse new project process. We have completed our initial incubation provisioning of the Eclipse Persistence Services Project (EclipseLink).

We now have our home page up ( with a wiki home and developer mailing list.

We are initiating the Eclipse Parallel IP review process to get the TopLink source and test case contribution into the subversion repository in the near future. This process of re-packaging and organizing the source has been very interesting.

In the coming weeks we'll get the source code in and builds and testing working. We'll publish our roadmap and focus on building new features and a strong community. Stay tuned....


Eclipse Persistence Services Project - Passed Creation Review


We are now busy working through the logistics of provisioning the product and getting the initial code contribution available through the parallel IP process.

If you have any questions please post them to the forum.



Simple Auditing using TopLink JPA


In a forum post on the Oracle TopLink forum on OTN there was a request for an approach to tracking entity history in a separate table. While Oracle TopLink includes support for automatic historical versioning this support does not exist in TopLink Essentials.The following is a simple example for how you might do historical versioning of your persistent entities using TopLink Essentials and JPA. There are many approaches to how you would design your schema for managing this additional state. I kept my approach simple where the primary data table uses an integer version optimistic locking column and the history table stores a row for each version of the primary table.The sample model is simply an Employee entity and its history is stored in an EmployeeHistory entity.@Entity@NamedQuery(name = "Employee.findAll", query = "select e from Employee e ORDER BY e.lastName ASC, e.firstName ASC")@TableGenerator(name = "emp-seq-table", table = "SEQUENCE", pkColumnName = "SEQ_NAME", valueColumnName = "SEQ_COUNT", pkColumnValue = "EMP_SEQ", allocationSize = 26)public class Employee { @Id @GeneratedValue(strategy = GenerationType.TABLE, generator = "emp-seq-table") @Column(name = "EMP_ID", nullable = false) private int id; @Column(name = "F_NAME") private String firstName; @Column(name = "L_NAME") private String lastName; private String gender; @Version private long version; ...@Entity@IdClass(EmployeeHistory.ID.class)@Table(name = "EMPLOYEE_HISTORY")@NamedQuery(name="EmployeeHistory.findAllForEmployee", query="SELECT eh FROM EmployeeHistory eh WHERE eh.employee = :EMP")public class EmployeeHistory { @Id @Column(name = "EMP_ID") private int id; @Id private long version; @ManyToOne @JoinColumn(name = "EMP_ID", referencedColumnName = "EMP_ID", insertable=false, updatable=false) private Employee employee; @Column(name = "F_NAME") private String firstName; @Column(name = "L_NAME") private String lastName; private String gender; /** * * @param emp */ protected EmployeeHistory(Employee emp) { = emp.getId(); this.version = emp.getVersion(); this.firstName = emp.getFirstName(); this.lastName = emp.getLastName(); this.gender = emp.getGender(); this.employee = emp; } ...Now to have the creation and modification of all Employee instances cause the creation of an EmployeeHistory instance I will use a TopLink Essentials specific event listener.The descriptor event listener used looks like:/*** This is an example of how a TopLink Essentials DescriptorEventListener can be* used to populate an audit record whenever an update occurs. This class must be* registered as a persistence unit property in the creation of the* EntityManagerFactory.** property name="toplink.descriptor.customizer.Employee" value="model.jpa.auditing.EmployeeAuditingHandler" ** @since TopLink Essentials v2-Build-41*/public class EmployeeAuditingHandler extends DescriptorEventAdapter implements DescriptorCustomizer { /** * This is where the real work of this class happens. For any INSERT or UPDATE * operation an INSERT of a new history object is forced. */ private void insertEmployeeHistory(DescriptorEvent event) { EmployeeHistory empHist = new EmployeeHistory((Employee)event.getSource()); InsertObjectQuery insertQuery = new InsertObjectQuery(empHist); event.getSession().executeQuery(insertQuery); } public void aboutToUpdate(DescriptorEvent event) { insertEmployeeHistory[...]

TopLink Essentials using Oracle Spatial ... a sample application


Andrejus Baranovskis has posted a sample application using Oracle Spatial with TopLink Essentials JPA. The steps are based upon my previous post.




Oracle Spatial using TopLink Essentials JPA As discussed in my previous post the usage of Oracle Database Spatial support is definitely growing in popularity. This post describes how TopLink Essentials, the reference implementation of JPA within GlassFish, can be extended to support mapping to MDSYS.SDO_GEOMETRY columns and leveraging the Oracle Spatial custom SQL operators within your queries. Extending TopLink Essentials (TLE) for Spatial support involves a couple of key steps: A custom database platform is required to handle the STRUCT <-> JGeometry (oracle.spatial.geometry) conversions and statement binding. Customize the mappings to ensure the default serialized mapping for the unknown JGeometry type is not used. Usage of custom TLE expression operators for defining the queries. 1. Custom Database Platform TLE uses a target database configuration to control custom SQL generation leveraging the different dialects supported by each of the database vendors. The platform is automatically detected by default but can be specified. For our purposes we will write a custom database platform extending the shipped OraclePlatform. To configure the use of our custom platform a persistence unit property ( will need to be set. The custom platform must be written and packaged where the class-loader can access it. Here is an example of what that platform might look like. 2. Customizing the Mappings The default mapping with JPA is to consider unknown types to be serialized basic (direct to field) mappings. In the case of JGeometry attribute types it is up to the developer to remove the converter that will be configured by default. The following descriptor customizer illustrates how the converter can be easily removed. /** * Descriptor customizer. This must be configured as a persistence unit property * for each entity type containing a JGeometry attribute. * * property name="toplink.descriptor.customizer.SimpleSpatial" value="model.jpa.spatial_simple.toplink.SimpleSpatialCustomizer" * */public class SimpleSpatialCustomizer implements DescriptorCustomizer { public void customize(ClassDescriptor descriptor) { DirectToFieldMapping mapping = (DirectToFieldMapping)descriptor.getMappingForAttributeName("geometry"); mapping.setConverter(null); }} 3. Using Custom Expression Operators While the above two steps are pretty straight forward with one time configurations the more involved process is using spatial operators across dynamic and named queries. Based on a set of custom expression operators the following examples illustrate how a named query definition and usage might look. EXAMPLE: Defining a Named Query with Custom Spatial Operators /** * Session customizer. This must be configured as a persistence unit property * for each entity type containing a JGeometry attribute. * *



Using Oracle Spatial with TopLink I have been working a growing number of customers assisting them with their usage of Oracle Database Spatial support through TopLink. Actually my first exposure with Spatial and TopLink dates back to 1999, long before I joined (through acquisition) Oracle. It was an extended consulting engagement assisting Oracle Consulting in their usage of TopLink on a customer's application. Those Oracle consultants are now my co-workers managing the Oracle Consulting teams I deal with and I am now product manager for TopLink. Our recent work assisting customers in their extensions of TopLink for Spatial data mapping and querying has already produced results (GE Energy Press Release).TopLink does not offer formal support for Oracle Spatial in the current 10.1.3.X versions or earlier. TopLink can however, be extended to support custom data types and query operators/functions. This post will walk through the basics of extended the expression framework and show some examples using Spatial data types.In order to have TopLink both read and write SDO_GEOMETRY columns as well as generate the necessary SQL to query these columns two extensions to TopLink need to be made.Provide a custom database platform enabling the SDO_GEOMETRY <-> JGeometry (oracle.spatial.geometry) conversionDefine and use custom expression operators to allow the generation of these operators into SQL I will leave it to you to read about the Oracle DB's Spatial support in the docs, on OTN or download a sample. Struct Conversions - Custom Database Platform The SDO_GEOMETRY object type which is used to store geometries in the database passes through JDBC as a Struct. The spatial Java library provides an implementation of JGeometry (oracle.spatial.geometry) that simplifies conversion and usage within a Java object model. In order to get TopLink to work with JGeometry types in the object model and properly handle the Struct with JDBC a custom database platform is required.Note: TopLink's existing support for mapping custom object types (Structs) is not an option with some Oracle Advanced Data Types such as Spatial. An active JDBC connection is required for conversion and the conversions at the mapping level do not necessarily have the connection available.Example 1: JGeometry - Struct Conversion Codepublic Object convertToObject(Struct struct) throws SQLException { if (struct == null) { return null; } return JGeometry.load((STRUCT)struct);}public Struct convertToStruct(Object geometry, Connection connection) throws SQLException { if (geometry == null) { return null; } return, connection);}To use these conversions within TopLink you must create a custom DatabasePlatform (most likely a subclass of Oracle10Platform) and incorporate these conversions into the platform. Custom Expression Operators TopLink's query framework makes use of expressions for defining the selection criteria as well as for specifying many query configuration options relative to the mapped object model. The expressions are basically a tree node object structure defining navigation through the mapped domain model as well as common query operators. For those of you more familiar with RedHatTM/JBossTM HibernateTM the expression framework provides a super-set of these capabilities to their criteria API. Using the TopLink expressions developers are able to build very complex queries and have the p[...]

A new home


With the launching of the Java Persistence Platform Project (aka EclipseLink) I decided to increase the scope of my blog so that it is not focussed just on TopLink. I also wanted to move to a different host.

After working on TopLink in many different roles for over a decade I am looking forward to this new challenge. Delivering a high quality open source solution in an open and transparent manor is our goal. I plan to make this blog my way to express my opinion on persistence related subjects and also deliver technical content to assist in the project's adoption.