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 10:01:32 GMT
Hi Michelle, Andy,

sorry I did not reply earlier.

I talked to Craig about this issue yesterday. We agreed on leaving 
"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" 
       <field name="id" primary-key="true">
         <column name="ID" jdbc-type="INTEGER"/>

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.


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

View raw message