Hi Frank,
I would approach your problem in a somewhat different manner than you
have taken. Here's why.
Any solution that you create in either OpenJPA or by overriding Kodo
classes may be fragile due to the evolution of the products. It is also
likely to be difficult, as you're discovering, due to a lack of
documentation of the internal workings of either OpenJPA or Kodo.
I think it would be much easier to write your own JDO metadata
manipulator, perhaps using a XSLT, to force the updating of on-site
deployed ORM files. Such code could then be integrated into your update
script that runs at customer sites. This code would be affected only by
the evolution of the JDO ORM schema which will be slow and well documented.
Cheers,
David Ezzio
Frank Jagla wrote:
Hello,
We are using BEA Kodo JDO, but I think my question can be solved within
the OpenJPA classes.
What I need is propagation of mapping hints from a package.jdo file to a
separate
and already existing package-mysql.orm file.
Consider the following example:
"package.jdo"
<class name="EmailPoImpl" detachable="true">
<inheritance>
<discriminator value="B.115.0" />
</inheritance>
<field name="message" default-fetch-group="true">
<column jdbc-type="longvarchar" />
</field>
</class>
"package-mysql.orm"
<class name="EmailPoImpl" table="EMAILPOIMPL">
<inheritance strategy="new-table">
<join column="ID"/>
<discriminator value="B.115.0"/>
</inheritance>
<field name="message">
<column name="MESSAGE" jdbc-type="varchar"/>
</field>
</class>
Our requirement is that the next invocation of MappingTool discovers the
"longvarchar" in the field meta data,
changes the orm file accordingly and the SchemaTool then emits an ALTER
TABLE MODIFY statement.
Can you please give me some hints into the source code? I am currently
investigating the parsers,
JDOMetaDataParser and JDORMetaDataParser, but I have the impression that
the crucial point is somewhere else,
maybe FieldMappingInfo or the Meta Data Repository.
Thank you very much.
