Peter Ondruška wrote:
Dear Kristian,
Regarding your remark about effectiveness of very small CLOB vs
VARCHAR should I just use VARCHAR to store 100 to 2000 character data
instead of CLOB? I do not want to index this column and storage size
and access speed (read only) are important.
Hi Peter,
It is hard to be sure without knowing the application, but based on what
you are saying in your mail I would say you should use VARCHAR instead
of CLOB for such small values.
In the scenario above you would run through a less complicated code
path, and also save three bytes for the header per value. The former
should make your accesses somewhat faster.
In a different thread I wrote that a single record select test got a
(normalized) throughput of 1.00 using VARCHAR and 0.77 using CLOB when
the value was 100 characters long.
If I get some free cycles, I may run the same test with the maximum
length allowed for the VARCHAR data type and see if the difference
changes. At least in 10.4, the result would depend on the value itself
as well (the bytes per char encoding ratio).
Regards,
--
Kristian
Thanks,
Peter
2009/6/19, Kristian Waagan <[email protected]>:
kashyup wrote:
Hello all,
We have just started to look into Derby as our embedded DB for a desktop
app
version.
Env: Hibernate 3.2 and Derby 10.5.1
I have defined a java string field of type 'text' in Hibernate Mapping
(works great on Postgres 8.1 and Oracle 10g)
I use Hibernate SessionFactory to generate Table schema, which is done
without any error.
But, when I try to save records in tables via Hibernate Session, I get the
following exception:
Note: If I change hibernate mapping to type 'string', then I dont get this
error:
java.lang.IllegalStateException: No context, unable to determine which
stream header format to generate
at
org.apache.derby.iapi.types.ClobStreamHeaderGenerator.determineMode(Unknown
Source)
at
org.apache.derby.iapi.types.ClobStreamHeaderGenerator.expectsCharCount(Unknown
Source)
at org.apache.derby.iapi.types.ReaderToUTF8Stream.fillBuffer(Unknown
Source)
at org.apache.derby.iapi.types.ReaderToUTF8Stream.read(Unknown Source)
at java.io.DataInputStream.read(Unknown Source)
at org.apache.derby.iapi.types.SQLClob.readExternal(Unknown Source)
at org.apache.derby.iapi.types.SQLChar.getString(Unknown Source)
at org.apache.derby.iapi.types.SQLClob.getClone(Unknown Source)
at org.apache.derby.impl.sql.GenericParameter.getClone(Unknown Source)
at org.apache.derby.impl.sql.GenericParameterValueSet.<init>(Unknown
Source)
at org.apache.derby.impl.sql.GenericParameterValueSet.getClone(Unknown
Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.addBatch(Unknown
Source)
at
org.hibernate.jdbc.BatchingBatcher.addToBatch(BatchingBatcher.java:31)
at
org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2252)
at
org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2665)
Also, I need to save it as type 'text' even though it gets saved as
CLOB(255), as the CLOB column size can later be altered.
What could be the cause? or changes needed?
Hello,
You have discovered / triggered a bug in the new Clob handling code
introduced in 10.5.1.
I logged DERBY-4278 [1], and have started working on a fix (the
regression tests are running, patch needs review).
Regarding workarounds, I'm afraid all I can think of is using the client
driver instead of the embedded driver, avoid batching for inserts with
Clobs, change the data type, or downgrade to 10.4. Another option is to
build Derby with the patch and test it out :)
I observe that you are using very small Clobs (255 characters). Clobs
are in general less effective than using for instance VARCHAR.
Is your concern about altering the column size related to Derby,
Hibernate or something else?
Regards,
--
Kristian
[1] https://issues.apache.org/jira/browse/DERBY-4278
thanks all
