openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Wrobel <kay.wro...@gmx.net>
Subject Re: PersistenceException: Invalid character string format for type int
Date Thu, 24 Oct 2013 21:53:24 GMT
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 <struberg@yahoo.de> wrote:
>
>> I agree. Can you please create a JIRA?
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: Kay Wrobel <kay.wrobel@gmx.net>
>>> 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:
>>>>>   <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 <kay.wrobel@gmx.net>
>>> 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/**<
>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>
>


Mime
View raw message