openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From plins...@gmail.com
Subject Re: Kodo 4 JDO Mappingtool - propagation of jdbc-type info
Date Wed, 11 Jul 2007 03:55:42 GMT
FYI, the reason that you're not seeing the updates is because those
extensions are only consulted when doing the initial mapping
generation, not on subsequent updates.

-Patrick

On 7/10/07, David Ezzio (asmtp) <dezzio@bea.com> wrote:
> 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.
> >
>
>


-- 
Patrick Linskey
202 669 5907

Mime
View raw message