openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Jagla <frank.ja...@skally.de>
Subject Re: Kodo 4 JDO Mappingtool - propagation of jdbc-type info
Date Wed, 11 Jul 2007 12:07:13 GMT
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) <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
>>
>>
>>

Mit freundlichen Grüßen
Frank Jagla


Mime
View raw message