On a recent project I was tasked with developing two domain objects which mapped via JPA to a couple of tables. This would have been easy apart from one table used the the Oracle-specific XMLTYPE data type:

The XMLTYPE datatype is not supported by JPA (or any Hibernate-specific annotations) and so I had to use a different approach. I created the JPA-based Person class as normal, adding @Column annotations to the class, ignoring the P_XML column. I then added the following bit of code to be a placeholder for the XML:

I then developed the JpaPersonDao as normal, using the getJpaTemplate() methods to select, insert and update the database. This handles all the columns except the XMLTYPE one - you need to use JDBC for that one due to the way in which Oracle expects the column to be filled and read.

My approach was to use the JPA-based DAO to perform most of the work loading and saving the rows, but hook in a JDBC-based DAO behind the scenes to handle the XMLTYPE column. By hiding it in the DAO, the users of the PersonDao will not have to worry about the special nature of the XMLTYPE column.

This is the JdbcPersonDao performing access to the XMLTYPE-based column only:

And here are the important bits of the JpaPersonDao hooking into the JDBC-based one to ensure that the data stays consistent, both accesses to the database are within the same transaction and so are atomic:

public Person updatePerson(Person person) { // put the xml to one side as the merge clears out the transient field String xml = person.getXml(); Person updatedPerson = getJpaTemplate().merge(person); updatedPerson.setXml(xml); saveXml(updatedPerson);