Return-Path: 
 <dev-return-22731-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org>
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 307091054F
	for <apmail-openjpa-dev-archive@www.apache.org>;
 Thu, 24 Oct 2013 21:05:29 +0000 (UTC)
Received: (qmail 76611 invoked by uid 500); 24 Oct 2013 20:54:07 -0000
Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org
Received: (qmail 76095 invoked by uid 500); 24 Oct 2013 20:53:53 -0000
Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@openjpa.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@openjpa.apache.org>
List-Post: <mailto:dev@openjpa.apache.org>
List-Id: <dev.openjpa.apache.org>
Reply-To: dev@openjpa.apache.org
Delivered-To: mailing list dev@openjpa.apache.org
Received: (qmail 75941 invoked by uid 99); 24 Oct 2013 20:53:24 -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:53:24 +0000
X-ASF-Spam-Status: No, hits=2.2 required=5.0
	tests=HTML_MESSAGE,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.19 as permitted sender)
Received: from [212.227.15.19] (HELO mout.gmx.net) (212.227.15.19)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 24 Oct 2013 20:53:17 +0000
Received: from [10.10.10.164] ([12.2.210.4]) by mail.gmx.com (mrgmx103) with
 ESMTPSA (Nemesis) id 0LyVcA-1VoHr515ew-015pKY for <dev@openjpa.apache.org>;
 Thu, 24 Oct 2013 22:52:57 +0200
Message-ID: <52698946.50406@gmx.net>
Date: Thu, 24 Oct 2013 15:55:34 -0500
From: Kay Wrobel <kay.wrobel@gmx.net>
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>
 <CAP=qHCsO6=6gMe6BUzjC2eqAa4wHzKVC_R3fyNBBh+HZVAmRFw@mail.gmail.com>
 <5269882D.20502@gmx.net>
In-Reply-To: <5269882D.20502@gmx.net>
Content-Type: multipart/alternative;
 boundary="------------040803000402010809050809"
X-Provags-ID: V03:K0:Bzj7HL8vgDLU/JBgMf6LYb8MaoS6RQF52SiZMQAGRQEpVOD4whZ
 nVzAakxwrULZgsAwYg02EaeHzuc+lnqNc1Riy5VyVsLEC2Hjnro+ChmNk4FYHAK0kaN8oDB
 cWBI/aoZmKaGpvrjwER/0m0UcFCf+2zFnU919L4IS60lW83MgM9hmRLO9jU/Urc1zxn5T1W
 +y1C42ZAfjaUY+yxwJSdw==
X-Virus-Checked: Checked by ClamAV on apache.org

--------------040803000402010809050809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ahhh.

Ok, so that line should read:
> <property name="openjpa.jdbc.DBDictionary" 
> value="storeCharsAsNumbers=false"/>
Now that got rid of the exception and the program continues without errors.

That now begs the question Mark raised earlier about assuming Chars to 
be of numeric content. I would say, switch that assumption around and 
let the user specify via the property above, like:
> <property name="openjpa.jdbc.DBDictionary" 
> value="storeCharsAsNumbers=*true*"/>
That would be more natural, I believe.



On 10/24/2013 03: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...
>> <property name="openjpa.jdbc.DBDictionary"
>> value="derby(storeCharsAsNumbers=false"/>
>>
>> If it doesn't work, enable trace and let us take a peek.
>> <property name="openjpa.Log" value="DefaultLevel=trace"/>
>>
>> Thanks,
>> Rick
>>
>>
>> On Thu, Oct 24, 2013 at 3:26 PM, Kay Wrobel <kay.wrobel@gmx.net> 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 <kay.wrobel@gmx.net>
>>>>> 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
>>>>> <https://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 
>>>>> <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
>>>>>
>>>>>
>>
>


--------------040803000402010809050809--