Re: unhappy with generated getTo methods

From: Heiko.Erhard..i-de.com
Date: Tue Feb 14 2006 - 07:29:49 EST

  • Next message: Gentry, Michael \(Contractor\): "RE: confluence woes"

    Tobias,

    good point at the right time.
    We just had to make the experience that after changing the database scheme
    (using the Oracle Designer) the numbering of the relations changed, i. e.
    what was relation1 in the recent reengineering run was now relation2. I
    don't blame Cayenne with this, I guess it's on the Oracle side when
    regenerating the schema - Cayenne just consumes the FK attributes as they
    come.
    However, this prevents us from having some kind of database model
    roundtrip. Really nasty.

    This is really nasty because we put quite some work into extending the
    reverse engineering feature of the modeler (haven't posted this to the list
    yet, however).

    - We wanted the method names to look like getPainting instead of
    getToPainting and getPaintingList instead of getPaintingArray or such.
    - We wanted to strip auto-generated attribute name prefixes from the object
    entity attributes (Oracle Designer is really great in this :-()
    - Also, we had requirements such as singularizing table names (e. g.
    PAINTINGS table -> Painting object entity, also considering exceptions like
    ADDRESSES -> Address o.e.).
    - An additional point was automatically generating sequence definitions
    when reverse engineering the database in order to achieve some kind of
    database model roundtrip when changing the database scheme.

    I made some extensions to 1.2M10 that address these issues. They can be
    easily customized using a properties file and allow for custom strategy
    classes to be specified (e. g. for creating sequence generator
    definitions).
    I think this mechanism could be extended to suit your needs.
    However, two suggestions:
    - I would want the mechanism that inserts the attribute name only become
    active when there is more than one relation from the source entity to a
    particular target entity.
    - Rules for automatically stripping prefixes should be applied to the
    attribute name before inserting it into the relation name

    Let me see what I can do.
    I will post our changes (maybe including a solution to your problem if I
    can find the time) to the list during the next days.
    Andrus or some other core developer might include them in the CVS version
    if they like them.

    --
    Heiko Erhardt
    

    Tobias SCHOESSLER <Tobias.Schoessle..nvienna.org> schrieb am 14.02.2006 09:49:56:

    > > hi, I sent this before, am not sure if it got through, I could't find my > post in the archives, so excuse me if it is a repost. > > I am not happy with the generated code for some of my databases structures > ... > > If a tableA has more than one foreign key relationship to the same other > tableB the generated getToTableB methods look like this. getToTableB1, > getToTableB2, getToTableB3 ... > Wouldn't it be better to have these methods named after the attribute of > the destination foreign key? if the foreign key attributes are attrA, > attrB, attrC. something like getToAttrATableA, getToAttrBTableB, ... > > This way If you have speaking attributes the relationship is much better > described. getToBadPainting, getToGoodPainting. A possibility would also to > pick up the name of the Constraint used to describe the foreign key > relation ... > > I tried to change this with a custom vl template but had problems getting > to the destination attribute from a Relationship ,,, maybe this should be > done somewhere else anyway... when the Realtionship's name is created > during reverse engineering process. > > I know the mapping can be changed manually, but I am trying to minimize the > manual work to be done to the mapping after reverse engineered. > > > > ______________________________________ > Tobias Schoessler, Java Developer > Information Management Unit > Information Technology Service > United Nations Office on Drugs and Crime > > Tel: (+43-1) 26060-5173 > Websites: www.unov.org, www.unodc.org > ______________________________________ > Impossible is not a fact, only an opinion >



    This archive was generated by hypermail 2.0.0 : Tue Feb 14 2006 - 07:30:02 EST