Re: unhappy with generated getTo methods

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Tue Feb 14 2006 - 17:42:53 EST

  • Next message: Andrus Adamchik: "Re: isIteratedResult and SPs"

    Heiko, Tobias --

    All this makes sense. Also see the earlier discussion of this topic:

    http://www.objectstyle.org/cayenne/lists/cayenne-user/2005/10/0164.html

    So I'd say this is a popular feature request.

    As Heiko pointed out, the solution is not in changing class
    generation templates, but rather in extending DbLoader. But maybe we
    can make DbLoader template driven?? Just an idea, there can be other
    solutions to that of course.

    Looking forward to your contributions. Please submit them via Jira
    issue tracker:

    http://objectstyle.org/cayenne/bugs-features.html

    Andrus

    On Feb 14, 2006, at 7:29 AM, Heiko.Erhard..i-de.com wrote:
    > 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



    This archive was generated by hypermail 2.0.0 : Tue Feb 14 2006 - 17:42:54 EST