I agree. Can you please create a JIRA?
LieGrue,
strub
----- Original Message -----
From: Kay Wrobel <[email protected]>
To: [email protected]
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:
<property name="openjpa.jdbc.DBDictionary"
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.
<property name="openjpa.jdbc.DBDictionary"
value="derby(
storeCharsAsNumbers=false)"/>
On Thu, Oct 24, 2013 at 3:50 PM, Kay Wrobel <[email protected]>
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
<[email protected]>
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 <[email protected]>
To: [email protected]
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/**<
https://raw.github.com/**kwrobel/OpenJPA-**IntExceptionTest/master/**>
OpenJPA-IntExceptionTest/****DiscountCode-Exception.txt<htt**
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 <https://github.com/kwrobel/****
OpenJPA-IntExceptionTest<
https://github.com/kwrobel/**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
