Return-Path: X-Original-To: apmail-openjpa-dev-archive@www.apache.org Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 10CF6104BA for ; Thu, 24 Oct 2013 20:47:34 +0000 (UTC) Received: (qmail 61836 invoked by uid 500); 24 Oct 2013 20:46:50 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 61490 invoked by uid 500); 24 Oct 2013 20:46:48 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 61276 invoked by uid 99); 24 Oct 2013 20:46:38 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Oct 2013 20:46:38 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of kay.wrobel@gmx.net designates 212.227.17.21 as permitted sender) Received: from [212.227.17.21] (HELO mout.gmx.net) (212.227.17.21) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Oct 2013 20:46:31 +0000 Received: from [10.10.10.164] ([12.2.210.4]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MBFUT-1VRVBO1OBZ-00ABqw for ; Thu, 24 Oct 2013 22:46:11 +0200 Message-ID: <526987B0.1030901@gmx.net> Date: Thu, 24 Oct 2013 15:48:48 -0500 From: Kay Wrobel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 MIME-Version: 1.0 To: dev@openjpa.apache.org Subject: Re: PersistenceException: Invalid character string format for type int References: <52697E3C.6040701@gmx.net> <1382645853.52360.YahooMailNeo@web28902.mail.ir2.yahoo.com> <5269828C.4050103@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:PBTMZf8skRRS2nzb4/BnqRjxXff+XOxZsTdJhk3GTwJ55S/KGxB O/scI9IDWUwaCXtfBDphnDGXONUgfiJSXnNT2ZQphKpD+uXRSf2i8fUIlJZNeS5hfx41GFF 5xnFHplojT5Eq3yc+5udS9aT0qIH+9NQ46MPxK3waHwfI9yMrORWr9c5GwcYHLfODo5JCsP MtebMYEnJrNcu2H7jLKRQ== X-Virus-Checked: Checked by ClamAV on apache.org Hi Curtis. In that same IRC, I had set the property as you requested and still received the same error. But I will try again to be double-sure. Kay On 10/24/2013 03:42 PM, Rick Curtis wrote: > As I suggested on IRC earlier this week, try setting the following property > to see if it makes things work... > value="derby(storeCharsAsNumbers=false"/> > > If it doesn't work, enable trace and let us take a peek. > > > Thanks, > Rick > > > On Thu, Oct 24, 2013 at 3:26 PM, Kay Wrobel wrote: > >> I have to make a correction to the last statement in my original post: The >> content values of DISCOUNT_CODE field are /*not*/ of numeric value, but >> actual characters, such as 'H' or 'M'. Sorry for causing confusion. >> >> >> On 10/24/2013 03:17 PM, Mark Struberg wrote: >> >>> My finding so far is that the DerbyDictionary doesn't overwrite >>> storeCharsAsNumbers, so it's still defaulted to true. >>> This code is exactly which trashes in the sample >>> >>> >>> Caused by: java.sql.SQLDataException: Invalid character string format for >>> type int. >>> at org.apache.derby.client.am.**SQLExceptionFactory40.**getSQLException(Unknown >>> Source) >>> at org.apache.derby.client.am.**SqlException.getSQLException(**Unknown >>> Source) >>> at org.apache.derby.client.am.**ResultSet.getInt(Unknown Source) >>> at org.apache.commons.dbcp.**DelegatingResultSet.getInt(** >>> DelegatingResultSet.java:225) >>> at org.apache.commons.dbcp.**DelegatingResultSet.getInt(** >>> DelegatingResultSet.java:225) >>> at org.apache.openjpa.lib.jdbc.**DelegatingResultSet.getInt(** >>> DelegatingResultSet.java:137) >>> at org.apache.openjpa.jdbc.sql.**DBDictionary.getInt(** >>> DBDictionary.java:841) >>> at org.apache.openjpa.jdbc.sql.**DBDictionary.getChar(** >>> DBDictionary.java:740) >>> at org.apache.openjpa.jdbc.sql.**ResultSetResult.** >>> getCharInternal(**ResultSetResult.java:300) >>> at org.apache.openjpa.jdbc.sql.**ResultSetResult.** >>> getObjectInternal(**ResultSetResult.java:377) >>> >>> The stacktrace is with todays 2.3.x branch snapshot. >>> >>> DBDictionary#getChar(): >>> public char getChar(ResultSet rs, int column) >>> throws SQLException { >>> if (storeCharsAsNumbers) >>> return (char) getInt(rs, column); <-- line 740 boom >>> ... >>> >>> The question for me is how Derby usually stores char fields internally. >>> Is our DerbyDictionary just wrong and should it set storeCharsAsNumbers >>> to false? >>> >>> There is of course the option to use @ColumnDefinition in the entity. >>> This should bypass this flag (I hope, didn't test it yet). >>> >>> LieGrue, >>> strub >>> >>> >>> >>> >>> ----- Original Message ----- >>> >>>> From: Kay Wrobel >>>> To: dev@openjpa.apache.org >>>> Cc: >>>> Sent: Thursday, 24 October 2013, 22:08 >>>> Subject: PersistenceException: Invalid character string format for type >>>> int >>>> >>>> Dear OpenJPA Dev Team, >>>> >>>> I am getting this exception >>>> >>> OpenJPA-IntExceptionTest/**DiscountCode-Exception.txt >>>> while reading a simple entity DiscountCode from a Derby database called >>>> SAMPLE (ships with Glassfish/NetBeans) called DISCOUNT_CODE that has >>>> only two fields: >>>> >>>> 1. DISCOUNT_CODE CHAR(1) NOT NULL PRIMARY KEY >>>> 2. RATE DECIMAL(4,2) NULL >>>> >>>> DISCOUNT_CODE maps to type "Character" and RATE maps to >>>> "BigDecimal". I >>>> set up a Github >>>> with a small test project. It's really small and concise. All you need >>>> to run this is a running Derby Network server with the SAMPLE database >>>> (included on the github), the latest OpenJPA library (I tested so far: >>>> 2.2.0 shipping with TomEE 1.5.2, 2.2.2 from the main project page, and >>>> 2.3.0-SNAPSHOT), the derby client driver (derby.jar, derbyclient.jar, >>>> derbynet.jar from the main Apache Derby distribution) and that's it. >>>> >>>> The curious part is that the field DiscountCode, though a char field, >>>> contains numeric, integer values. Mark Struberg seems to have a hunch >>>> already of what is going on and is able to add some more insight. >>>> >>>> Any input on this is greatly appreciated. >>>> >>>> Regards, >>>> >>>> Kay Wrobel >>>> >>>> >