You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Frank Jagla <fr...@skally.de> on 2007/07/10 13:35:49 UTC
Kodo 4 JDO Mappingtool - propagation of jdbc-type info
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.
--
Mit freundlichen Grüßen
Frank Jagla
--------------------------------------------
skally - Gesellschaft für Logistik- und Informationssysteme mbH, Konrad-Zuse-Straße 10, 44801 Bochum
Amtsgericht Bochum, HRB 4297; USt-ID-Nr. DE198585621; Geschäftsführer: Reimund Ott, Wolfgang A. Vitt
Telefon: 0234 - 9708 500 Telefax: 0234-9708 501 E-Mail: service@skally.de
Haftungsausschluss:
Diese Nachricht enthält vertrauliche Informationen und ist ausschließlich für den Adressaten bestimmt. Falls Sie die Daten irrtümlich erhalten haben, nehmen Sie bitte Kontakt mit dem Absender auf und
löschen Sie die Daten auf jedem Computer und Datenträger. Die skally GmbH ist nicht verantwortlich für die ordnungsgemäße, vollständige und verzögerungsfreie Übertragung der Nachricht. Der Inhalt der
E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend bestätigt wird.
Re: Kodo 4 JDO Mappingtool - propagation of jdbc-type info
Posted by Frank Jagla <fr...@skally.de>.
Hi David, hi Patrick,
I appreciate your advice, but nevertheless i would like to understand the inner workings
of the mapping and schema tools.
My intention is to develop a hot patch for use in my company that helps us over the next few weeks.
And of course, OpenJPA is a fascinating peace of software thats a pleasure to study!
So, please, if possible, can you give some hints where to look? Where do those extensions get
consulted? Who decides on initial mapping / subsequent update?
Cheers
Frank Jagla
plinskey@gmail.com schrieb:
> 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) <de...@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
>>
>>
>>
Mit freundlichen Grüßen
Frank Jagla
Re: Kodo 4 JDO Mappingtool - propagation of jdbc-type info
Posted by pl...@gmail.com.
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) <de...@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
Re: Kodo 4 JDO Mappingtool - propagation of jdbc-type info
Posted by "David Ezzio (asmtp)" <de...@bea.com>.
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.
>