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:47:54 GMT
Hi again Michael,

To further clarify, I agree that we want to leave the fld_char and 
fld_Character fields of AllTypes as INTEGER and change the orm to 
specify the jdbc-type.  However, I think that Andy was correct in saying 
that the tables FIELDSOFCHARACTER and FIELDSOFPRIMITIVECHAR should have 
CHAR(1) columns.  I already made that change.  I haven't looked at 
PCPointSingleFieldChar, so I have no opinion about that one.

-- 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