Re: Reengineering Overwrites

From: Robert Zeigler (robert.zeigle..mail.com)
Date: Thu Apr 09 2009 - 01:51:42 EDT

  • Next message: John Armstrong: "Re: Reengineering Overwrites"

    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.

    Robert

    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 [mailto:ar..sh.com.au]
    > Sent: Thursday, 9 April 2009 3:50 p.m.
    > To: use..ayenne.apache.org
    > 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
    >
    > _Artist.java
    >
    > and then you modify
    >
    > Artist.java
    >
    > 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
    > http://www.ish.com.au
    > 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.



    This archive was generated by hypermail 2.0.0 : Thu Apr 09 2009 - 01:56:44 EDT