cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Zeigler <>
Subject Re: Reengineering Overwrites
Date Thu, 09 Apr 2009 05:51:42 GMT
Have you tried using the "migrate" functionality?
Although the default directionality is from your model to the  
database, you can reverse the directionality and go from the database  
back to your model.  I haven't played with this much so YMMV, but it's  
worth looking into.


On Apr 8, 2009, at 4/811:28 PM , Weddle, Anthony wrote:

> Well, if I do reverse engineering in the modeler, the process wants to
> create new ObjEntity entries. For any table that I accept an overwrite
> for, it creates a new corresponding ObjEntity. I thought it might
> overwrite the old one but it creates a new one, with a unique suffix.
> This newly created ObjEntity doesn't know anything about changes I may
> have made to the original one, instead, it just uses the table
> definition in the DbEntity as a basis.
> There may actually be valid schema changes that have found their way  
> to
> the newly created ObjEntity which I'd want to merge into the existing
> customised ObjEntity for the table.
> For example, suppose I customised a Java type to be an extended type,
> instead of a String. If I change that table in the schema (perhaps
> adding or removing columns, and changing varchar widths) and use the
> reverse engineering function, I get an ObjEntity that has a different
> name to the existing ObEntity and doesn't have any of the manual
> customisations I made. I don't really want to have to re-do my
> customisations, especially as there may be several classes that have  
> had
> schema changes and there is no way to easily see which tables have
> changed.
> As we have over 170 tables in the schema that we use, I wouldn't  
> want to
> manually go through every generated ObjEntity to check for, and re-do,
> customisations and also wouldn't want to manually delete the unneeded
> ObjEntities that were generated.
> There are other potential changes to the ObjEntity but the above is a
> common example.
> Tony
> -----Original Message-----
> From: Aristedes Maniatis []
> Sent: Thursday, 9 April 2009 3:50 p.m.
> To:
> Subject: Re: Reengineering Overwrites
> On 09/04/2009, at 1:18 PM, Weddle, Anthony wrote:
>> We occasionally make database schema changes. We also modify some of
>> the
>> attributes of ObjEntity entries. It looks like a reverse engineering
>> run
>> would ignore any changes to ObjEntity entries. Is there any way to
>> have
>> changes merged?
> You should make all the additions you need to the subclass. So you'll
> have
> and then you modify
> with your overrides.
> However, you are able to specify ID generation strategy, superclasses,
> relationships and extended types in the modeler. Is there something
> specific you are wanting to do which you find missing in the modeler?
> Regards
> Ari
> -------------------------->
> ish
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001   fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> NOTICE - This message and any attached files may contain information  
> that is confidential, legally privileged or proprietary.  It is  
> intended only for use by the intended recipient. If you are not the  
> intended recipient or the person responsible for delivering the  
> message to the intended recipient, be advised that you have received  
> this message in error. Any dissemination, copying, use or re- 
> transmission of this message or attachment, or the disclosure of any  
> information therein, is strictly forbidden. BlueScope Steel Limited  
> does not represent or guarantee that this message or attachment is  
> free of errors, virus or interference.
> If you have received this message in error please notify the sender  
> immediately and delete the message.  Any views expressed in this  
> email are not necessarily the views of BlueScope Steel Limited.

View raw message