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
