db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michelle Caisse <Michelle.Cai...@Sun.COM>
Subject Re: JIRA JDO-68
Date Tue, 02 Aug 2005 15:58:20 GMT
Okay, agreed.  -- Michelle

Michael Watzek wrote:

> Hi Michelle,
>
> please have a look at test "TestFieldsOfCharacter". It uses 
> "java.lang.Charcater.MAX_VALUE" and "java.lang.Character.MIN_VALUE".
>
> Concerning test "TestFieldsOfPrimitivechar" I am wrong. This test 
> initializes character fields using real characters like 'a'. For this 
> reason, I agree to change the column types to "CHAR(1)" for table 
> "FIELDSOFPRIMITIVECHAR".
>
> Regards,
> Michael
>
>> Michael,
>>
>> Where are the numerical value initializations that you speak of for 
>> FieldsOfCharacter and FieldsOfPrimitivechar?  I don't see it.
>>
>> -- Michelle
>>
>> Michael Watzek wrote:
>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>
>


Mime
View raw message