db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Watzek <mwa.t...@spree.de>
Subject Re: JIRA JDO-68
Date Tue, 02 Aug 2005 15:50:00 GMT
Hi Andy,

I changed the column types of table "FIELDSOFCHARACTER" back to INTEGER. 
I also changed the ORM metadata for class "FieldsOfCharacter", e.g.

         <class name="FieldsOfPrimitivechar" table="FIELDSOFPRIMITIVECHAR">
             ...
             <field name="char0">
                 <column name="CHAR0" jdbc-type="INTEGER"/>
             </field>
             ...
          </class>

Running test "TestFieldsOfCharacter" I receive an exception at 
pm.makePeristent (see below). Looking at the stacktrace it seems that 
JPOX calls PreparedStatement.setString though I specified "INTEGER" above.

The bound value is "java.lang.Character.MIN_VALUE". The same happens for 
  "java.lang.Character.MAX_VALUE". I do not receive an exception when I 
bind a char value like '1' and '2'.

I'm using JPOX nightly build 2005-08-01. Can you please check and verify 
if JPOX calls "PrepraredStatement.setString" for the case above?

Regards,
MIchael

     [java] ERROR 22018: Invalid character string format for type INTEGER.
     [java]      at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java)
     [java]      at 
org.apache.derby.iapi.types.DataType.invalidFormat(DataType.java)
     [java]      at 
org.apache.derby.iapi.types.SQLInteger.setValue(SQLInteger.java)
     [java]      at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement.setString(EmbedPreparedStatement.java)
     [java]      at 
org.jpox.store.rdbms.mapping.CharRDBMSMapping.setObject(CharRDBMSMapping.java:531)
     [java]      at 
org.jpox.store.mapping.SingleFieldMapping.setObject(SingleFieldMapping.java:235)
     [java]      at 
org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:129)
     [java]      at 
org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2402)
     [java]      at 
org.apache.jdo.tck.pc.fieldtypes.FieldsOfCharacter.jdoProvideField(FieldsOfCharacter.java)
     [java]      at 
org.apache.jdo.tck.pc.fieldtypes.FieldsOfCharacter.jdoProvideFields(FieldsOfCharacter.java)
     [java]      at 
org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:2740)
     [java]      at 
org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:241)
     [java]      at 
org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:1750)
     [java]      at 
org.jpox.store.StoreManager.insert(StoreManager.java:721)
     [java]      at 
org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3092)
     [java]      at 
org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3065)
     [java]      at 
org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1014)
     [java]      at 
org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1050)
     [java]      at 
org.apache.jdo.tck.models.fieldtypes.TestFieldsOfCharacter.runTest(TestFieldsOfCharacter.java:90)
     [java]      at 
org.apache.jdo.tck.models.fieldtypes.TestFieldsOfCharacter.test(TestFieldsOfCharacter.java:66)
     [java]      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
     [java]      at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     [java]      at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     [java]      at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:197)
     [java]      at 
org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:128)
     [java]      at 
org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:106)

> Hi Michelle, Andy,
> 
> sorry I did not reply earlier.
> 
> I talked to Craig about this issue yesterday. We agreed on leaving 
> tables "FIELDSOFCHARACTER", "FIELDSOFPRIMITIVECHAR", and 
> "PCPointSingleFieldChar" as they are keeping the INTEGER columns.
> 
> The rationale is that pc class instances mapped to those tables have 
> character values which are initialized based on numerical values rather 
> than character values, e.g. "Character.MAX_VALUE", 
> "Character.MIN_VALUE", or "System.currentTimeMillis()%Character.MAX_VALUE".
> 
> For this reason, we decided to adapt the ORM metadata rather than to 
> adapt the schema: <field> elements corresponding to fields of type 
> "char" or "java.lang.Character" will have "jdbc-type" attributes, e.g.
> 
>     <class name="PCPointSingleFieldPrimitivechar" 
> table="PCPointSingleFieldChar">
>       <field name="id" primary-key="true">
>         <column name="ID" jdbc-type="INTEGER"/>
>       </field>
>       ...
>     </class>
> 
> For pc classes like "HashtableStringValueCollections" (etc.) the story 
> is slightly different:
> 
> They have several fields of type "java.util.Map" where (sometimes) keys 
> are FCOs (e.g. SimpleClass instances) and values are strings. The types 
> of keys and values differ and can be derived by the classname.
> 
> Each of these fields is mapped to a separate (join) table having join 
> columns, key columns, value columns, and index columns. In the current 
> schema, all of these columns have type "INTEGER".
> 
> This is a bug: Keys and values of type "java.lang.String" must be mapped 
> to columns of type "VARCHAR". Furthermore, join tables which are mapped 
> by fields of maps or sets do not have index columns. Question: Do we 
> have to distinguish bewteen sorted maps/sets vs. non-sorted maps/sets?
> 
> I'll prepare two patches today fixing these issues - one for each 
> identity type.
> 
> Regards,
> Michael
> 
>> Hi Andy,
>>
>> This is really good, a big improvement in the error count.
>>
>> Andy Jefferson wrote:
>>
>>> ...
>>> Schema where column is INTEGER but should be CHAR(1)
>>> FieldsOfCharacter : table FIELDSOFCHARACTER has INTEGER columns
>>> FieldsOfPrimitivechar : table FIELDSOFPRIMITIVECHAR has INTEGER columns
>>>  
>>>
>> I am fixing these.
>>
>>> Schema where column is INTEGER but should be VARCHAR(...)
>>> HashMapStringKeyCollections, HashMapStringValueCollections, 
>>> MapStringKeyCollections, MapStringValueCollections, 
>>> TreeMapStringKeyCollections, TreeMapStringValueCollections : join 
>>> tables have the key as INTEGER instead of VARCHAR
>>>  
>>>
>> I agree that the KEYVAL columns in *StringKeyCollections and the 
>> VALUEVAL columns of *StringValueCollections should be VARCHAR.  We 
>> have some other fixes we need to make to the mapping for these, so 
>> I'll make these changes with those.
>>
>>> Also, this change may affect other JIRA issues, but sadly 
>>> "http://issues.apache.org" is about as unresponsive a server as I've 
>>> ever come across, so we'll have to leave that for others to work out ;-)
>>>
>>>  
>>>
>> The server seems to have come to life again.  I will update the issues 
>> soon.
>>
>> -- Michelle
> 
> 
> 


-- 
-------------------------------------------------------------------
Michael Watzek                  Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de        Buelowstr. 66
Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
Fax.:  ++49/30/217 520 12       http://www.spree.de/
-------------------------------------------------------------------

Mime
View raw message