openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Ezzio (asmtp)" <dez...@bea.com>
Subject Re: Kodo 4 JDO Mappingtool - propagation of jdbc-type info
Date Tue, 10 Jul 2007 18:37:54 GMT
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.
> 


Mime
View raw message