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 AA850107AE for ; Thu, 24 Oct 2013 21:51:15 +0000 (UTC) Received: (qmail 14587 invoked by uid 500); 24 Oct 2013 21:51:15 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 14432 invoked by uid 500); 24 Oct 2013 21:51:14 -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 14206 invoked by uid 99); 24 Oct 2013 21:51:13 -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 21:51:13 +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.15.15 as permitted sender) Received: from [212.227.15.15] (HELO mout.gmx.net) (212.227.15.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Oct 2013 21:51:07 +0000 Received: from [10.10.10.164] ([12.2.210.4]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MCLx3-1VQQNT32Th-0095Av for ; Thu, 24 Oct 2013 23:50:46 +0200 Message-ID: <526996D4.2060903@gmx.net> Date: Thu, 24 Oct 2013 16:53:24 -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> <5269882D.20502@gmx.net> <52698E4C.2050206@gmx.net> <52698F14.1060107@gmx.net> <1382649654.96585.YahooMailNeo@web28906.mail.ir2.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ElbMAkyrjcPZuB5aKof+A+PMh/eVbxRDuEnYu/sUgh2jiDotjYd eMBX3eLfL4mhIzHmkVgbEmBFN9mgC/8cXO59HGzPPK0QTWMJzQKe/X9kXwpHvx6kRBNA+vk RzhNER72AaKnAIF1Ryih3vseHvEme/nBkbeP5YpQdOVvIWTO4LZAxyEW043+Zxt7wjgh0Kx 2f2L6lEPREF9IDkf4AdGA== X-Virus-Checked: Checked by ClamAV on apache.org Alright. I see everybody's predicament and understand the argument behind it. I myself have seen code that's 15+ years old and would feel the same way. That said, it would then be something that should maybe be pointed out somewhere in clear terms that this is the default behavior, and the more natural mapping of CHARs as characters and not numerics can be enabled using the property you guys mentioned. This screems documentation at the very least. On 10/24/2013 04:36 PM, Albert Lee wrote: > I would hesitate to change the default since nothing is broken. This DB > property default has been around for a long time and if the default is > changed, very likely it will break compatibility with application migrating > to the changed release. > > Albert Lee. > > > On Thu, Oct 24, 2013 at 4:20 PM, Mark Struberg wrote: > >> I agree. Can you please create a JIRA? >> >> LieGrue, >> strub >> >> >> >> >> ----- Original Message ----- >>> From: Kay Wrobel >>> To: dev@openjpa.apache.org >>> Cc: >>> Sent: Thursday, 24 October 2013, 23:20 >>> Subject: Re: PersistenceException: Invalid character string format for >> type int >>> I just confirmed the problem also had existing using MySQL. >>> I recreated the table and records for DISCOUNT_CODE in a MySQL database >>> and had the same exception and the property setting (both versions) got >>> rid of the error. >>> >>> Still, this should default to "false" imho. >>> >>> >>> >>> On 10/24/2013 04:17 PM, Kay Wrobel wrote: >>>> Ja, I actually used: >>>>> >>>> value="storeCharsAsNumbers=false"/> >>>> and that works as well. >>>> >>>> On 10/24/2013 03:54 PM, Rick Curtis wrote: >>>>> Sorry, I wrote that quickly.... yes it was missing a ')'. If >>> that >>>>> doesn't >>>>> work, please collect trace. >>>>> >>>>> >> value="derby( >>>>> storeCharsAsNumbers=false)"/> >>>>> >>>>> >>>>> On Thu, Oct 24, 2013 at 3:50 PM, Kay Wrobel >>> wrote: >>>>>> Are you sure value is derby(storeCharsAsNumbers=**false??? That >>> looks >>>>>> wrong somehow. >>>>>> >>>>>> The "(" in there. >>>>>> >>>>>> >>>>>> 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. >>>>>>> >> value="DefaultLevel=trace"/> >>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>> IntExceptionTest/master/**< >> https://raw.github.com/**kwrobel/OpenJPA-**IntExceptionTest/master/**> >>>>>>>>>> >>> OpenJPA-IntExceptionTest/****DiscountCode-Exception.txt>> ps://raw.github.com/kwrobel/**OpenJPA-IntExceptionTest/** >>> master/OpenJPA-**IntExceptionTest/DiscountCode-**Exception.txt< >> https://raw.github.com/kwrobel/OpenJPA-IntExceptionTest/master/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 >>>>>>>>> >>> OpenJPA-IntExceptionTest< >> https://github.com/kwrobel/**OpenJPA-IntExceptionTest> >>>>>>>>>> >>> > https://github.com/kwrobel/OpenJPA-IntExceptionTest> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> > >