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.wro...@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.wro...@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
>>>
>>>
>
--
*Rick Curtis*
