Should I be able to simply map a java.lang.String property as type="text", have the string data stored as a CLOB and read and write to that field?

The data in the java.lang.String is a bas64-encoded GIF file. With one version of the JayBird JDBC driver I get the "charsetName" exception when I try to read the data back. When I retried with their latest driver, the exception occured while trying to save the data.

I've seen info about special CLOB handling for Oracle, etc., so I thought I should first ask if I need to do more than map a String as "text" for this to work.

I don't see a place in the mapping to specify a character set, and both InputStreamReader and OutputStreamWriter appear to have a constructor that takes no character set and uses the system default.

Any help/redirection appreciated,
-Jeff

Hibernate version: 3.0.5

Mapping documents:



Code between sessionFactory.openSession() and session.close():

getHibernateTemplate().saveOrUpdate(layout);

Full stack trace of any exception that occurs:

java.lang.NullPointerException: charsetName
at java.io.OutputStreamWriter.<init>(Unknown Source)
at org.firebirdsql.jdbc.FBBlob.copyCharacterStream(FBBlob.java:544)
at org.firebirdsql.jdbc.field.FBLongVarCharField.copyCharacterStream(FBLongVarCharField.java:237)
at org.firebirdsql.jdbc.field.FBLongVarCharField.flushCachedData(FBLongVarCharField.java:214)
at org.firebirdsql.jdbc.AbstractPreparedStatement.flushFields(AbstractPreparedStatement.java:723)
at org.firebirdsql.jdbc.AbstractPreparedStatement.internalExecute(AbstractPreparedStatement.java:697)
at org.firebirdsql.jdbc.AbstractPreparedStatement.executeUpdate(AbstractPreparedStatement.java:164)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:94)
at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:22)
at org.hibernate.persister.entity.BasicEntityPersister.insert(BasicEntityPersister.java:1853)
at org.hibernate.persister.entity.BasicEntityPersister.insert(BasicEntityPersister.java:2200)
at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:46)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:239)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:223)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:136)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:274)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:730)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:324)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:86)
at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(HibernateTransactionManager.java:490)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:495)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:468)
at org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(TransactionAspectSupport.java:258)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
at $Proxy8.saveWelcomeScreen(Unknown Source)
at com.lexmark.workflow.framework.tools.DataLoader.loadMonteCarloWelcomeScreen(DataLoader.java:396)
at com.lexmark.workflow.framework.tools.DataLoader.loadWelcomeScreens(DataLoader.java:480)
at com.lexmark.workflow.framework.tools.DataLoader.loadAllData(DataLoader.java:164)
at com.lexmark.workflow.framework.tools.DataLoader.main(DataLoader.java:543)


Name and version of the database you are using:

Firebird 1.5.2

The generated SQL (show_sql=true):

Hibernate: insert into WELCOME_LAYOUT (NUMFIRSTPAGEBUTTONS, LAYOUTTYPE, CLASS_DISC, LAYOUT_ID) values (?, ?, 'MC', ?)
Hibernate: insert into WELCOME_BUTTON (PROFILENAME, ICONTEXT, BUTTON_TYPE, UPICON, DOWNICON, PERSIST, CLASS_DISC, BUTTON_ID) values (?, ?, ?, ?, ?, ?, 'MC', ?)

I don't understand why you want to store binary data as a string. I would use byte[] as type for storing gifs (which are BLOBs, not CLOBs).

Sometimes the same data appears in our system inside XML files, so base64-encoding it seemed reasonable so that (we thought) we'd never have to treat the data with kid gloves.

The point is, it IS just a big string, so why can't I map it to a type="text" and have Hibernate worry about CLOBS for me?

-Jeff

Jeff, databases do not treat strings "as is". The first line of the stacktrace gives you a pointer: charsetName. Databases translate strings they get in to the charset the database is using.

You don't want any translation (you can never translate it back to the original string) so the only way to be sure your string is stored verbatim is by using a blob.

That sounds like absolute drivel, and not just because I'm reading it at 2:19 am. Why in the world would Hibernate offer a mapping from java.lang.String to "text" that wouldn't return you back the original string?

I'm pretty sure I've found the ANSWER to this on the Firebird-java list. They appear to have a bug in their JDBC driver.

-Jeff

Try this then.

Set your DB charset to ISO-8859-1 and then have a differently encoded string with various high characters that do not appear in ISO-8859-1. Write the string to your db and read it back, compare the two and note the difference.