From derby-user-return-11187-apmail-db-derby-user-archive=db.apache.org@db.apache.org Tue Jun 30 13:38:49 2009 Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 94886 invoked from network); 30 Jun 2009 13:38:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 30 Jun 2009 13:38:45 -0000 Received: (qmail 12423 invoked by uid 500); 30 Jun 2009 13:38:55 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 12363 invoked by uid 500); 30 Jun 2009 13:38:55 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 12355 invoked by uid 99); 30 Jun 2009 13:38:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jun 2009 13:38:55 +0000 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [192.18.6.21] (HELO gmp-eb-inf-1.sun.com) (192.18.6.21) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Jun 2009 13:38:43 +0000 Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5UDcNOZ005077 for ; Tue, 30 Jun 2009 13:38:23 GMT MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; format=flowed; charset=windows-1252 Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KM100H00ZHKWO00@fe-emea-09.sun.com> for derby-user@db.apache.org; Tue, 30 Jun 2009 14:38:23 +0100 (BST) Received: from [129.159.139.223] ([unknown] [129.159.139.223]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KM2009ZU0JCWZ90@fe-emea-09.sun.com> for derby-user@db.apache.org; Tue, 30 Jun 2009 14:38:01 +0100 (BST) Date: Tue, 30 Jun 2009 15:36:29 +0200 From: Kristian Waagan Subject: Re: Hibernate + Derby - Unable to determine stream header for hibernate type 'text' In-reply-to: <4d2670740906190941g3e74394dgae177ba38174caab@mail.gmail.com> Sender: Kristian.Waagan@Sun.COM To: Derby Discussion Message-id: <4A4A14DD.5030700@Sun.COM> References: <24099674.post@talk.nabble.com> <4A3BB308.6020105@Sun.COM> <4d2670740906190941g3e74394dgae177ba38174caab@mail.gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) X-Virus-Checked: Checked by ClamAV on apache.org 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 : > >> 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.(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 >>> >>> >>> >>> >>