[
https://issues.apache.org/jira/browse/DERBY-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12589183#action_12589183
]
Thomas Nielsen commented on DERBY-3621:
---------------------------------------
Based on your original email[1] to derby-user earlier today, as well as the
current description and synopsis, I believe this is not a Derby issue.
The mapping from Hibernate 'text' type to Derby 'clob' type happens in the
Hibernate dialects code which is part of Hibernate, not Derby.
If there is an issue in this area it should be filed with the Hibernate
community.
[1]
http://www.nabble.com/derby---hibernate---type-%27text%27-to16692245.html#a16692245
> Hibernate. Derby uses type 'text' as clob(255) instead of long varchar
> ----------------------------------------------------------------------
>
> Key: DERBY-3621
> URL: https://issues.apache.org/jira/browse/DERBY-3621
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.2.1
> Environment: OS: Windows, Derby 10.3.2.1, Hibernate 3.1 (same problem
> with newer versions)
> Reporter: Aleksander Rozman
>
> Hi !
> It seems that when type 'text' is used with Hibernate (indicating type text
> in database, which is varchar with no length defined-unlimited) Derby
> converts this definition to CLOB(255).
> --------- Original code is set to
> registerColumnType( Types.CLOB, "clob($l)" );
> This then procudes CLOB(255), which means that Derby gives it only 255
> character. Even if we dont use long varchar and use clob, we should at least
> give it max value for derby (this would fix most of problems, except in case
> where entry could be long varchar).
> --------- This is my hack (which doesn't work)
> I tried to "hack" hibernate and added following definition into
> DerbyDialect...
> registerColumnType(Types.LONGVARBINARY, "long varchar for bit data");
> registerColumnType(Types.LONGVARCHAR, "long varchar");
> registerColumnType(Types.CLOB, "long varchar");
> When I use type='text', then it always falls into Type.CLOB. This hack made
> it to be long varchar, which then produced error....
> Caused by: java.sql.SQLDataException: An attempt was made to get a data value
> of type 'LONG VARCHAR' from a data value of type 'CLOB'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.newSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.dataTypeConversion(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.setNull(Unknown
> Source)
> at org.hibernate.type.NullableType.nullSafeSet(NullableType.java:76)
> at org.hibernate.type.NullableType.nullSafeSet(NullableType.java:60)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:1826)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:1803)
> at
> org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2059)
> ------------------
> Any kind of fix would be helpful. I am trying to find *any* pure java
> database that works with Hibernate... Each have their own problems... Hsqldb
> is to slow when used on USB (it works very fast, but shutdown is problem),
> Mckoi works very slow, but shgutdown is fast, this one doesn't work...
> Problem is that I need to have "portable" database, since my application
> should be also used on USB disk....
> I hope this will be resolved...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
